Zookeeper典型应用场景篇

1

Zookeeper应用场景

2

Zookeeper分布式锁

我们将锁抽象成目录，多个线程在此目录下创建瞬时的序列节点，因为Zk会为我们保证节点的序列性，所以可以利用节点的序列进行锁的判断。

首先创建序列节点进行升序排序，然后获取当前目录下最小的节点，判断最小节点是不是当前节点，如果是那么获取锁成功，如果不是那么获取锁失败。

获取锁失败的节点获取当前节点上一个顺序节点，对此节点注册监听，当节点删除的时候通知当前节点。

当unlock的时候删除节点之后会通知下一个节点。

3

ZK VS Redis 锁对比

4

ZK命名服务-ID生成器

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

41-bit的时间可以表示（1L

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

优点：

毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。

不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。

可以根据自身业务特性分配bit位，非常灵活。

解决时钟问题

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

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

若写过，则用自身系统时间与leaf_forever/$节点记录时间做比较，若小于leaf_forever/$时间则认为机器时间发生了大步长回拨，服务启动失败并报警。

若未写过，证明是新服务节点，直接创建持久节点leaf_forever/$并写入自身系统时间，接下来综合对比其余Leaf节点的系统时间来判断自身系统时间是否准确，具体做法是取leaf_temporary下的所有临时节点(所有运行中的Leaf-snowflake节点)的服务IP：Port，然后通过RPC请求得到所有节点的系统时间，计算sum(time)/nodeSize。

若abs( 系统时间-sum(time)/nodeSize )

否则认为本机系统时间发生大步长偏移，启动失败并报警。

每隔一段时间(3s)上报自身系统时间写入leaf_forever/$。

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客户端的实现原理：

客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过Http Long Polling实现）

客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。

这是一个fallback机制，为了防止推送机制失效导致配置不更新

客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified

定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property:来覆盖，单位为分钟。

客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中

客户端会把从服务端获取到的配置在本地文件系统缓存一份

在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置

应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知

配置中心对比如下：

6

Zookeeper注册发现

dubbo注册中心

调用关系说明

服务容器负责启动，加载，运行服务提供者。

服务提供者在启动时，向注册中心注册自己提供的服务。

服务消费者在启动时，向注册中心订阅自己所需的服务。

注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

Eureka VS ZK

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

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

7

Zookeeper在Haddoop应用

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

今天就到这~