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专栏中详细介绍

今天就到这~

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180615G21AI800?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券