Zookeeper典型应用场景篇

1、Zookeeper应用场景


2、Zookeeper分布式锁


  • 我们将锁抽象成目录，多个线程在此目录下创建瞬时的序列节点，因为Zk会为我们保证节点的序列性，所以可以利用节点的序列进行锁的判断。
  • 首先创建序列节点进行升序排序，然后获取当前目录下最小的节点，判断最小节点是不是当前节点，如果是那么获取锁成功，如果不是那么获取锁失败。
  • 获取锁失败的节点获取当前节点上一个顺序节点，对此节点注册监听，当节点删除的时候通知当前节点。
  • 当unlock的时候删除节点之后会通知下一个节点。


3、ZK VS Redis 锁对比



4、ZK命名服务-ID生成器

zk特性：顺序节点的特性+snowflake方案


41-bit的时间可以表示（1L<<41）/(1000L*3600*24*365)=69年的时间，10-bit机器可以分别表示1024台机器。如果我们对IDC划分有需求，还可以将10-bit分5-bit给IDC，分5-bit给工作机器。这样就可以表示32个IDC，每个IDC下可以有32台机器，可以根据自身需求定义。12个自增序列号可以表示2^12个ID，理论上snowflake方案的QPS约为409.6w/s，这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的。

到家采用：1+41+5+5+12 方案 即：时间+ center_id +worker_id+随机数

Id:案例：995961692951035904 =18位

优点：

  1. 毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。
  2. 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
  3. 可以根据自身业务特性分配bit位，非常灵活。


解决时钟问题

因为这种方案依赖时间，如果机器的时钟发生了回拨，那么就会有可能生成重复的ID号，需要解决时钟回退的问题。


参见上图整个启动流程图，服务启动时首先检查自己是否写过ZooKeeper leaf_forever节点：

  1. 若写过，则用自身系统时间与leaf_forever/${self}节点记录时间做比较，若小于leaf_forever/${self}时间则认为机器时间发生了大步长回拨，服务启动失败并报警。
  2. 若未写过，证明是新服务节点，直接创建持久节点leaf_forever/${self}并写入自身系统时间，接下来综合对比其余Leaf节点的系统时间来判断自身系统时间是否准确，具体做法是取leaf_temporary下的所有临时节点(所有运行中的Leaf-snowflake节点)的服务IP：Port，然后通过RPC请求得到所有节点的系统时间，计算sum(time)/nodeSize。
  3. 若abs( 系统时间-sum(time)/nodeSize ) < 阈值，认为当前系统时间准确，正常启动服务，同时写临时节点leaf_temporary/${self} 维持租约。
  4. 否则认为本机系统时间发生大步长偏移，启动失败并报警。
  5. 每隔一段时间(3s)上报自身系统时间写入leaf_forever/${self}。


5、Zookeeper配置中心

为什么要用统一配置？

我们做项目时用到的配置比如数据库配置等...我们都是写死在项目里面，如果需要更改，那么也是的修改配置文件然后再投产上去，那么问题来了，如果做集群的呢，有100台机器，这时候做修改那就太不切实际了；那么就需要用到统一配置管理啦。

解决思路

1.把公共配置抽取出来

2.对公共配置进行维护

3.修改公共配置后应用不需要重新部署

采用方案

1.公共配置抽取存放于zookeeper中并落地数据库或配置文件中

2.对公共配置修改后发布到zookeeper中并落地数据库或配置文件中

3.对应用开启配置实时监听，zookeeper配置文件一旦被修改，应用可通过watch实时监听到并获取


Disconf设计方案


Disconf通过disconf-web管理配置信息，然后将配置的key在Zookeeper上建立节点，disconf-client启动后拉取自身需要的配置信息并监听Zookeeper的节点。在web上更新配置信息会触发zk节点状态的变动，client可以实时感知到变化，然后从web上拉取最新配置信息。



Apollo架构设计



上图简要描述了Apollo客户端的实现原理：

  1. 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过Http Long Polling实现）
  2. 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。
  • 这是一个fallback机制，为了防止推送机制失效导致配置不更新
  • 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
  • 定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。
  • 客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
  • 客户端会把从服务端获取到的配置在本地文件系统缓存一份
  • 在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
  • 应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知


配置中心对比如下：



6、Zookeeper注册发现

dubbo注册中心


节点角色说明Provider暴露服务的服务提供方Consumer调用远程服务的服务消费方Registry服务注册与发现的注册中心Monitor统计服务的调用次数和

调用时间的监控中心Container服务运行容器


调用关系说明

  1. 服务容器负责启动，加载，运行服务提供者。
  2. 服务提供者在启动时，向注册中心注册自己提供的服务。
  3. 服务消费者在启动时，向注册中心订阅自己所需的服务。
  4. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
  5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
  6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

Eureka VS ZK


Eureka的哲学是，同时保留”好数据“与”坏数据“总比丢掉任何”好数据“要更好

从注册发现的角度上来看 Eureka 优于 ZK


7、Zookeeper在Haddoop应用

zk在Haddoop生态中主要起到了服务协调作用，具体应用会在Hadoop专栏中详细介绍

编辑于 2019-06-03 20:30
ZooKeeper
Hadoop
分布式系统