ZooKeeper 分布式配置——看这篇就够了
ZooKeeper 的由来
PS:这一节不重要, 不感兴趣的小伙伴可以跳过
ZooKeeper 最早起源于雅虎研究院的一个研究小组,在当时,研究人员发现,在雅虎内部有很多的大型系统基本上都需要依赖一个类似的系统来进行分布式协调,但是这些系统往往都存在分布式单点的问题,所有雅虎的开发人员就尝试开发了一个通用的无单点问题的分布式协调框架,以便让开发人员将精力集中在处理业务逻辑上。关于"ZooKeeper"这个项目的名字。也有一个故事,在项目开始初期,因为考虑到内部的很多项目都是用动物的名字来命名的(例如:Pig 项目),所以雅虎的工程师也希望给这个项目也取一个动物的名字,这个时候担任研究院的首席科学家 Raghu Ramakrishnan 开玩笑地说:“在这样下去,我们这儿就变成动物园”,此话一出,大家纷纷表示就叫动物园管理员吧,因为各个以动物命名的分布式组件放在一起,这个分布式系统看上去就像一个大型的动物园了,而 ZooKeeper 正好要用来进行分布式环境的协调,于是 ZooKeeper 的名字也就由此诞生了。
来源:《从 Paxos 到 ZooKeeper 》
分布式配置中心
在上一期中我们讲解了 ZooKeeper 集群的配置和安装,ZooKeeper 集群 主要是帮我们做分布式协调的,今天我们用 ZK 实现分布式配置。关于 ZooKeeper 集群的配置大家可以参考上一篇文章《Zookeeper 集群部署的那些事儿》。
为什么需要分布式配置中心
对于刚开始的时候,很多公司的服务器可能是由单个组成,但是随着业务的发展,单一节点的服务无法满足业务的飞速发展,后面就出现了分布式、集群的概念,到了现在形成的微服务,技术的改进能够更好的满足业务的需要。
假设我们线上有很多个微服务分布在不同的服务器上,其中一个微服务,我们就叫它 goods-service
,当 goods-service
的 IP 地址需要变更的时候,但是 goods-service
又对很多其他的程序提供了服务,这个时候如果没有一个统一配置的东西,每一个应用到 goods-service
的应用程序都要做相应的 IP 地址修改,这是一个很麻烦的事情!
如果使用 ZooKeeper 来做分布式配置的话,是可以解决这个问题的。
注册中心对比
如果我们只考虑服务治理的话,Eureka 是比较合适的,Eureka 是比较纯粹的注册中心了,和 Eureka 不同 Apache ZooKeeper 在设计的时候就遵循 CP 原则,任何时候对 ZooKeeper 的访问请求都能得到一致的数据结果,同事系统对网络分割具有容错性,今天我们讲解的就是关于 ZooKeeper 的注册发现。
配置中心的核心
低延迟: 配置改变(
create/update/delete
)后能够最快的把最新的配置同步到其他节点中高可用: 配置中心可以稳定的对外提供服务
其中 低延迟 我们可以通过 ZooKeeper 的 Watcher 机制来实现(等下会讲到 Watcher 机制)。约定一个节点用来存放配置信息,每个客户端都来监听这个节点的 NodeDataChanged 事件,当配置发生改变时将最新的配置更新到这个节点上,谁更新无所谓,任何节点都可以更新,当这个节点触发 NodeDataChanged 事件后,在去通知所有监听这个节点的客户端去获取这个节点的最新信息,因为 watcher 是一次性的,所以当我们在获取最新信息的时候需要设置监听事件,大部分查询信息都是具有原子性的,所以 ZooKeeper 中的 getData 也是具有原子性操作,能够保证我们取得的信息是最新的。
对于 高可用 我们首先需要保证的多集群操作来进行 ZooKeeper 进行部署,在代码层不太需要做过多的工作。
Watch 机制
Watch 是 ZooKeeper 针对节点的一次性观察者机制,就如同我们上面 ** 低延迟** 中讲到的,一次触发后就失效,需要手工重新创建 Watch。
当 Watch 监视的数据发生变化的时候,就会通知设置了 Watch 的客户端,就是我们 API 中的 Watcher,Watcher 机制就是为了监听 Znode 节点发生了哪些变化,所以会有对应的事件类型和状态类型,用过代码中 switch 进行监听,一个客户端可以链接多个节点,只要 Znode 节点发生变化就会执行 process(WatchedEvent event)
。
如下图所示:
从上图中我们可以看到,在 ZooKeeper 中,Watch 采用的是推送机制,而不是客户端轮询,有些中间件采用的是拉取的模式,例如:KafKa。
Watch 有两种监听模式,分别为 事件类型和状态类型 :
事件类型:Znode 节点关联,主要是针对节点的操作
创建节点:EventType.NodeCreated
节点数据发生变化:EventType.NodeDataChanged
当前节点的子节点发生变化:EventType.NodeChildrenChanged
删除节点:EventType.NodeDeleted
状态类型:客户端关联,主要是针对于 ZooKeeper 集群和应用服务之间的状态的变更
未连接:KeeperState.Disconnected
已连接:KeeperState.SyncConnected
认证失败:KeeperState.AuthFailed
过期:KeeperState.Expired
客户端连接到只读服务器:KeeperState.ConnectedReadOnly
watch 的特性
一次性触发: 对于 ZooKeeper 的 Watcher 事件,是一次性触发的,当 Watch 监视的数据发生变化的时候,通知设置当前 Watch 的 Client,就是我们对应的 Watcher,因为 ZooKeeper 的监控都是一次性的,所以我们需要在每次触发后设置监控。
客户端串行执行: 客户端 Watcher 回调的过程是一个串行同步的过程,可以为我们保证顺序的执行。
轻量级: WatchedEvent 是 ZooKeeper 整个 Watcher 通知机制的最小通知单元,总共包含三个部分(通知状态、事件类型和节点路径),Watcher 通知,只会告诉客户端发生事件而不会告知具体内容,需要客户端主动去进行获取,比如 当监听到 WatchedEvent.NodeDataChanged 信息变化的时候,只会告诉我们这个节点的数据发生了变更,你快来获取最新的值吧。
客户端设置的每个监视点与会话关联,如果会话过期,等待中的监视点将会被删除。不过监视点可以跨越不同服务端的连接而保持,例如,当一个 ZooKeeper 客户端与一个 ZooKeeper 服务端的连接断开后连接到集合中的另一个服务端,客户端会发送未触发的监视点列表,在注册监视点时,服务端将要检查已监视的 znode 节点在之前注册监视点之后是否已经变化,如果 znode 节点已经发生变化,一个监视点的事件就会被发送给客户端,否则在新的服务端上注册监视点。这一机制使得我们可以关心逻辑层会话,而非底层连接本身。
客户端注册
ZooKeeper 注册的时候会向 ZooKeeper 服务端请求注册,服务端会返回请求响应,不管成功失败,都会返回响应结果,当响应成功的时候,ZooKeeper 服务端会把 Watcher 对象放到客户端的 WatchManager 管理并返回响应给客户端
服务端注册
FinalRequest Processor.ProcessRequest()
会判断当前请求是否需要注册 Watcher
如果 ZooKeeper 判断当前客户端需要进行 Watcher 注册,会将当前的 ServerCnxn 对象和数据路径传入 getData 方法中去。ServerCnxn 是 ZooKeeper 客户端和服务端之间的连接接口,代表了一个客户端和服务端的连接,可以将 ServerCnxn 当做一个 Watcher 对象,因为它实现了 Watcher 的 process 接口。
WatcherManager
WatcherManager 是 ZK 服务端 Watcher 的管理器,分为 WatchTable 和 Watch2Paths 两个存储结构,这两个是不同的存储结构 1)WatchTable: 从数据节点路径的颗粒度管理 Watcher2)Watch2Paths:从 Watcher 的颗粒度来控制时间出发的数据节点
在服务端,DataTree 中会托管两个 WatchManager, 分别是 dataWatches (数据变更 Watch) 和 childWatches(子节点变更 Watch)。
Watcher 触发逻辑
1)封装 WatchedEven:将(KeeperState(通知状态),EventType(事件类型),Path(节点路径))封装成一个 WatchedEvent 对象 2)查询 Watcher:根据路径取出对应的 Watcher,如果存在,取出数据同时从 WatcherManager(WatchTable/Watch2Paths) 中删除 3)调用 Process 方法触发 Watcher
4.客户端回调 Watcher
1)反序列化:字节流转换成 WatcherEvent 对象 2)处理 chrootPath:如果客户端设置了 chrootPath 属性,那么需要对服务器传过来的完整节点路径进行 chrootPath 处理,生成客户端的一个相对节点路径。比如(/mxn/app/love,经过 chrootPath 处理,会变成 /love)3)还原 WatchedEvent:WatcherEvent 转换成 WatchedEvent4)回调 Watcher:将 WatcherEvent 对象交给 EventThread 线程,在下一个轮询周期中进行 Watcher 回调
EventThread 处理时间通知
1) SendThread 接收到服务端的通知事件后,会通过调用 EventThread.queueEvent 方法将事件传给 EventThread 线程 2)queueEvent 方法首先会根据该通知事件,从 ZKWatchManager 中取出所有相关的 Watcher 客户端识别出 事件类型 EventType 后,会从相应的 Watcher 存储 (即 3 个注册方法( dataWatches、existWatcher 或 childWatcher)中去除对应的 Watcher3) 获取到相关的所有 Watcher 后,会将其放入 waitingEvents 这个队列去
代码实现
下面我们就来演示如何使用代码来实现 ZooKeeper 的配置
首先我们需要引入 ZK 的 jar
配置类
既然我们要做的是分布式配置,首先我们需要模拟一个配置,这个配置用来同步服务的地址
Watcher
创建 ZooKeeper 的时候,我们需要一个 Watcher 进行监听,后续对 Znode 节点操作的时候,我们也需要使用到 Watcher,但是这两类的功能不一样,所以我们需要定义一个自己的 watcher 类,如下所示:
由于是异步进行操作的,我们创建一个 ZooKeeper 对象之后,如果不进行阻塞操作的话,有可能还没有连接完成就执行后续的操作,所以这里我们用 CountDownLatch
进行阻塞操作,当监测连接成功后,进行 countDown
放行,执行后续的 ZK 的动作。
当我们连接成功 ZooKeeper 之后,我们需要通过 exists
判断是否存在节点,存在就进行 getData 操作。这里我们创建一个 WatchCallBack
因为exists和getData都需要一个callback
,所以除了实现 Watcher 以外还需要实现节点状态:AsyncCallback.StatCallback 数据监听:AsyncCallback.DataCallback
当前面准备好了之后,我们可以编写测试用例了:
ZKUtils 工具类
测试类:
运行测试
首先我们要知道,因为我们连接 IP 的时候加上了 /mxn
这个目录结构,所以我们在服务器初始状态就必须要有这个节点:
集群初始状态:
我们启动程序看看连接成功
ZooKeeper 下 /mxn 现在也是空
现在我们来创建一个/mxn/myZNode
节点数据
可以看到,创建完成之后,程序马上给出响应,打印出了我配置的值,muxiaonong666
此时,再设置/mxn/myZNode
的值为 muxiaonong6969
啪,很快啊!!!我们就可以看到值瞬间改变了
这个时候我们如果删除/mxn/myZNode
节点,会发生什么呢,前面我们已经写了 watch,如果 Znode 被删除了,,watch and callback 执行
删除/mxn/myZNode
节点delete /mxn/myZNode
我们可以看到前面还在打印数据,后面就提示丢失。
但是这个时候我们客户端没有关闭,而是还在等待数据的更新,如果这个时候当重新进行创建/mxn/myZNode
节点的时候,程序又会继续疯狂输出。create /mxn/myZNode "muxiaonong666"
程序正常运行,并且成功获取到了 zk 配置的最新数据,到这里基本上就实现了,ZooKeeper 的分布式配置中心功能了
在这里我测试用的是
getData
,但是在项目实战用可能用的更多的是 子节点的操作getChildren
总结
到这里我们这篇 ZooKeeper 分布式配置注册发现 就讲完了,如果有疑问的地方欢迎进行讨论,ZooKeeper 可以作为分布式配置中心,也可以用来当然微服务的注册,不过现在微服务都有自己的一套服务发现,对于了解 ZooKeeper 可以我们方便我们在进行技术选型的时候更好的去抉择, ZooKeeper 的高可用和最终一致性也是比较稳定,
本文代码地址:https://github.com/muxiaonong/ZooKeeper/tree/master/mxnzookeeper 如果对你有帮助,请帮忙 star,感谢!
我是牧小农,如果对你有帮助的话,记得一键三连啊,怕什么真理无穷,进一步有一步的欢喜,大家加油 ~
版权声明: 本文为 InfoQ 作者【牧小农】的原创文章。
原文链接:【http://xie.infoq.cn/article/4b1201a0a50a9e3b5d572d62a】。文章转载请联系作者。
评论