中小研发团队架构实践之分布式协调器ZooKeeper
Apache ZooKeeper是由Apache Hadoop的子项目发展而来，于2010年11月正式成为了Apache的顶级项目。
ZooKeeper是一个开放源代码的分布式协调服务。它具有高性能、高可用的特点，同时也具有严格的顺序访问控制能力（主要是写操作的严格顺序性）。基于对ZAB协议（ZooKeeper Atomic Broadcast，ZooKeeper原子消息广播协议）的实现，它能够很好地保证分布式环境中数据的一致性。也正是基于这样的特性，使得ZooKeeper成为了解决分布式数据一致性问题的利器。
ZooKeeper整体架构
请见上图，文字说明如下：
ZooKeeper由两部分组成：ZooKeeper服务端和客户端。
ZooKeeper服务器采用集群的形式。值得一提的是，只要集群中存在超过一半的、处于正常工作状态的服务器，那么整个集群就能够正常对外服务。组成ZooKeeper集群的每台服务器都会在内存中维护当前的ZooKeeeper服务状态，并且每台服务器之间都互相保持着通信。
客户端在连接ZooKeeper服务集群时，会按照一定的随机算法选择集群中的某台服务器，然后和它共同创建一个TCP连接，使客户端连上到那台服务器。而当那台服务器失效时，客户端自动会重新选择另一台服务器进行连接，从而保证服务的连续性。
当其中一个客户端修改数据时，ZooKeeper会将修改同步到集群中所有的服务器上，从而使连接到集群中其它服务器上的客户端也能立即看到修改后的数据，很好地保证了分布式环境中数据的一致性。
ZooKeeper数据模型
请见上图，文字说明如下：
Zookeeper的数据模型采用类似于文件系统的树结构。树上的每个节点称为ZNode，而每个节点都可能有一个或者多个子节点。ZNode的节点路径标识方式是由一系列斜杠【/】进行分割的路径表示。
可以向ZNode节点写入、修改、读取数据，也可以创建、删除ZNode节点或ZNode节点下的子节点。值得注意的是，ZooKeeper的设计目标不是传统的数据库存储或者大数据对象存储，而是协同数据的存储，因此在实现时ZNode存储的数据大小不应超过1MB。另外，每一个节点都有个ACL（Access Control List，访问控制列表），据此控制该节点的访问权限。
ZNode数据节点是有生命周期的，其生命周期的长短取决于数据节点的节点类型。节点类型共有4种：持久节点（PERSISTENT）、持久顺序节点（PERSISTENT_SEQUENTIAL）、临时节点（EPHEMERAL）、临时顺序节点（EPHEMERAL_SEQUENTIAL）。
ZooKeeper的Watcher机制，概括为三个过程：客户端注册Watcher成为订阅者、服务端处理Watcher以及客户端回调Watcher。
客户端在自己需要关注的位于ZooKeeper服务器里的ZNode节点上注册一个Watcher监听后，一旦这个ZNode节点发生变化，则在该节点上注册过Watcher监听的所有客户端会收到ZNode节点变化通知。在收到通知时，客户端通过回调Watcher做相应的处理，从而实现特定的功能。
通过对ZooKeeper中丰富的数据节点类型进行交叉使用，配合Watcher事件通知机制，可以非常方便地构建分布式应用中都会涉及的核心功能，如：数据发布/订阅（即配置中心）、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等。
Demo中的【ConfigServiceDemo（配置服务Demo）】适用于ZooKeeper的配置中心应用场景：
应用中用到的一些常用配置信息放到ZooKeeper的一系列ZNode节点上，供应用获取配置数据；同时，如果某应用在需要关注的配置项节点上注册了个Watcher，则以后每次被关注的配置项有更新的时候，都会实时通知到该应用，从而达到获取最新配置信息的目的。
a. 减少我们的运维工作人员的工作量：当公司的应用程序以集群环境模式被部署的时候，若第1次部署应用程序或遇到需要配置新增/修改/删除的情况，我们的运维工作人员不得不为集群中的每台服务器进行一台一台地修改。而利用了ZooKeeper后，他们只需要修改一次，就能为集群中的所有服务器完成配置新增/修改/删除。
b. 使任意客户端能够看到即时生效的被改后的配置数据：目前现状：由于运维工作人员需要为集群中的每台服务器进行一台一台地配置修改，而导致出现了配置延时问题，使得集群中的每台服务器的配置数据不一致。也就是说，客户端（如应用程序）可能会无法立即读取到最新的配置值，需要过段时间后才能读取到。当运维工作人员利用ZooKeeper修改配置数据后，新的配置数据会立即被同步到集群中的所有服务器，从而保证集群中的所有服务器的配置数据对于任意客户端而言每时每刻都是准确无误的（可选加Watcher）。
下图显示的是ZooKeeper配置服务页面。
我们都知道，集群中的服务器一般只有1台起着Master角色。一旦这台具有Master角色的服务器出现宕机情况，则就出现了服务器单点故障问题。并且，我们并不知道这台具有Master角色的服务器是从什么时候开始处于宕机状态。利用ZooKeeper的“对在ZooKeeper上创建的临时顺序节点（EPHEMERAL_SEQUENTIAL），一旦创建它的客户端与ZooKeeper服务集群之间的会话失效，那么该临时节点也就被自动清除”这一特性，再加上Watcher事件通知机制的使用，就能够解决服务器的单点故障问题——一旦当前具有Master角色的服务器宕机了，它创建的临时顺序节点（EPHEMERAL_SEQUENTIAL）会马上消失；紧接着集群中注册过Watcher的所有服务器会马上收到当前Master服务器已宕机的通知，然后将重新进行Master选举。
- ZooKeeperDemo下载地址：https://github.com/das2017/ZooKeeperDemo
- ZooKeeper（v3.4.10） 官网：http://zookeeper.apache.org/doc/r3.4.10/
- ZooKeeper客户端下载地址：https://github.com/ewhauser/zookeeper
posted on 2019-01-10 18:39 arch-system 阅读(1650) 评论(4) 编辑 收藏 举报
