阿里P8架构师谈：Zookeeper的原理和架构设计，以及应用场景

什么是 Zookeeper

Zookeeper 分布式服务框架是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：

1. 统一命名服务
2. 状态同步服务
3. 集群管理
4. 分布式应用配置项的管理等

Zookeeper已经成为Hadoop生态系统中的基础组件。

Zookeeper的基本原理和架构

1、Zookeeper的角色

» 领导者（leader）：负责进行投票的发起和决议，更新系统状态。

» 学习者（learner）：包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票。

» Observer：可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度

» 客户端（client）：请求发起方

• Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。

Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

• 为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

• 每个Server在工作过程中有三种状态：

LOOKING：当前Server不知道leader是谁，正在搜寻

LEADING：当前Server即为选举出来的leader

FOLLOWING：leader已经选举出来，当前Server与之同步

其他文档：http://www.cnblogs.com/lpshou/archive/2013/06/14/3136738.html

2、Zookeeper 的读写机制

» Zookeeper是一个由多个server组成的集群

» 一个leader，多个follower

» 每个server保存一份数据副本

» 全局数据一致

» 分布式读写

» 更新请求转发，由leader实施

3、Zookeeper 的保证

» 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行

» 数据更新原子性，一次数据更新要么成功，要么失败

» 全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的

» 实时性，在一定事件范围内，client能读到最新数据

4、Zookeeper节点数据操作流程

1.在Client向Follwer发出一个写的请求

2.Follwer把请求发送给Leader

3.Leader接收到以后开始发起投票并通知Follwer进行投票

4.Follwer把投票结果发送给Leader

5.Leader将结果汇总后如果需要写入，则开始写入同时把写入操作通知给Leader，然后commit;

6.Follwer把请求结果返回给Client

•

5、Zookeeper工作原理

» Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。

Zab协议有两种模式，它们分别是：恢复模式和广播模式。

当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。

6、数据一致性与paxos 算法

• 据说Paxos算法的难理解与算法的知名度一样令人敬仰，所以我们先看如何保持数据的一致性，这里有个原则就是：

• 在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。

• Paxos算法解决的什么问题呢，解决的就是保证每个节点执行相同的操作序列。好吧，这还不简单，master维护一个全局写队列，所有写操作都必须 放入这个队列编号，那么无论我们写多少个节点，只要写操作是按编号来的，就能保证一致性。没错，就是这样，可是如果master挂了呢。

• Paxos算法通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，

只有获得过半数选票的写操作才会被 批准（所以永远只会有一个写操作得到批准），其他的写操作竞争失败只好再发起一

轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排 序。编号严格递增，当一个节点接受了一个

编号为100的写操作，之后又接受到编号为99的写操作（因为网络延迟等很多不可预见原因），它马上能意识到自己 数据

不一致了，自动停止对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性（总2n+1台，除非挂掉大于n台）。

总结

• Zookeeper 作为 Hadoop 项目中的一个子项目，是 Hadoop 集群管理的一个必不可少的模块，它主要用来控制集群中的数据，

如它管理 Hadoop 集群中的 NameNode，还有 Hbase 中 Master Election、Server 之间状态同步等。

关于Paxos算法可以查看文章 Zookeeper全解析——Paxos作为灵魂

推荐书籍：《从Paxos到Zookeeper分布式一致性原理与实践》

7、Observer

• Zookeeper需保证高可用和强一致性；

• 为了支持更多的客户端，需要增加更多Server；

• Server增多，投票阶段延迟增大，影响性能；

• 权衡伸缩性和高吞吐率，引入Observer

• Observer不参与投票；

• Observers接受客户端的连接，并将写请求转发给leader节点；

• 加入更多Observer节点，提高伸缩性，同时不影响吞吐率

8、 为什么zookeeper集群的数目，一般为奇数个？

•Leader选举算法采用了Paxos协议；

•Paxos核心思想：当多数Server写成功，则任务数据写成功如果有3个Server，则两个写成功即可；如果有4或5个Server，则三个写成功即可。

•Server数目一般为奇数（3、5、7）如果有3个Server，则最多允许1个Server挂掉；如果有4个Server，则同样最多允许1个Server挂掉由此，

我们看出3台服务器和4台服务器的的容灾能力是一样的，所以为了节省服务器资源，一般我们采用奇数个数，作为服务器部署个数。

9、Zookeeper 的数据模型

» 层次化的目录结构，命名符合常规文件系统规范

» 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识

» 节点Znode可以包含数据和子节点，但是EPHEMERAL类型的节点不能有子节点

» Znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本

» 客户端应用可以在节点上设置监视器

» 节点不支持部分读写，而是一次性完整读写

10、Zookeeper 的节点

» Znode有两种类型，短暂的（ephemeral）和持久的（persistent）

» Znode的类型在创建时确定并且之后不能再修改

» 短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点

» 持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除

» Znode有四种形式的目录节点

» PERSISTENT（持久的）

» EPHEMERAL（暂时的）

» PERSISTENT_SEQUENTIAL（持久化顺序编号目录节点）

» EPHEMERAL_SEQUENTIAL（暂时化顺序编号目录节点）

Zookeeper的应用场景

1. 配置管理

这个好理解，分布式系统都有好多机器，比如我在搭建hadoop的HDFS的时候，需要在一个主机器上（Master节点）配置好HDFS需要的各种配置文件，然后通过scp命令把这些配置文件拷贝到其他节点上，这样各个机器拿到的配置信息是一致的，才能成功运行起来HDFS服务。

Zookeeper提供了这样的一种服务：一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的都可以获得变更。这样就省去手动拷贝配置了，还保证了可靠和一致性。

2. 名字服务

这个可以简单理解为一个电话薄，电话号码不好记，但是人名好记，要打谁的电话，直接查人名就好了。

分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务；

• 类似于域名与ip之间对应关系，域名容易记住；
• 通过名称来获取资源或服务的地址，提供者等信息

3. 分布式锁

碰到分布二字貌似就难理解了，其实很简单。单机程序的各个进程需要对互斥资源进行访问时需要加锁，那分布式程序分布在各个主机上的进程对互斥资源进行访问时也需要加锁。很多分布式系统有多个可服务的窗口，但是在某个时刻只让一个服务去干活，当这台服务出问题的时候锁释放，立即fail over到另外的服务。这在很多分布式系统中都是这么做，这种设计有一个更好听的名字叫Leader Election（leader选举）。举个通俗点的例子，比如银行取钱，有多个窗口，但是呢对你来说，只能有一个窗口对你服务，如果正在对你服务的窗口的柜员突然有急事走了，那咋办？找大堂经理（zookeeper）!大堂经理指定另外的一个窗口继续为你服务！

4. 集群管理

在分布式的集群中，经常会由于各种原因，比如硬件故障，软件故障，网络问题，有些节点会进进出出。有新的节点加入进来，也有老的节点退出集群。这个时候，集群中有些机器（比如Master节点）需要感知到这种变化，然后根据这种变化做出对应的决策。我已经知道HDFS中namenode是通过datanode的心跳机制来实现上述感知的，那么我们可以先假设Zookeeper其实也是实现了类似心跳机制的功能吧！

你可能也喜欢:

1. 如何从0到1设计一个类Dubbo的RPC框架
2. 阿里P8架构师谈：从单体架构、到SOA、再到微服务的架构设计详解
3. 阿里P8架构师谈：微服务Dubbo和SpringCloud架构设计、优劣势比较
4. 阿里P8架构师谈：Spring Cloud与Dubbo的详细比较
5. RPC框架的实现原理，及RPC架构组件详解
6. 阿里P8架构师谈：Restful、SOAP、RPC、SOA、微服务之间的区别

---