ZooKeeper是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper通过其简单的架构和API解决了这个问题。ZooKeeper允许开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。
zk的核心算法为ZAB(原子消息广播协议)，与Paxos不同，这是一种特别为zk设计的崩溃可恢复的原子消息广播算法,ZAB的架构可见下文：
https://distributedalgorithm.wordpress.com/2015/06/20/architecture-of-zab-zookeeper-atomic-broadcast-protocol/
而ZAB的核心如下：
所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器称为Leader服务器，而余下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal(提议)，并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交
zab协议包括两个基本模式：消息广播以及崩溃恢复
消息广播流程示意图如下：
image.png
（图片来自从Paxos到zk）
正如图中所示，部署zk集群至少需要有三个节点，否则zab就没要办法实现，实际上为了保证选举顺利，通常采用奇数个节点
崩溃恢复：
一旦Leader服务器出现崩溃，或者由于网络原因导致Leader服务器失去了过半Follower的联系，那么就会进入崩溃恢复模式，并且恢复后需要一个新的leader，因此zab协议需要一个高效且可靠的选举机制
一旦Leader服务器出现崩溃，或者由于网络原因导致Leader服务器失去了过半Follower的联系，那么就会进入崩溃恢复模式，并且恢复后需要一个新的leader，因此zab协议需要一个高效且可靠的选举机制，
这种机制必须能够确保提交已经被Leader提交的事务Proposal，同时丢弃已经被跳过的事务Proposal。
(1)旧Leader宕机后，选举新Leader中，旧的Leader重启后不可能再次成为这次选举的新Leader。
(2)旧Leader宕机后，在剩下的Follower服务器选取新Leader的标准，一定是事务ID最大的那个Follower成为新Leader。（即数据同步最新的那台Follower服务器）
(3)事务ID（ZXID）是64位的数字。其中低32位可以靠做是一个简单的单调递增的计数器，高32位则代表一个Leader从生到死的epoch编号。
(4)新Leader选举出来，从事务proposal中分析出旧Leader的epoch编号，并递增1,作为新的事务ID的高32位，然后新事务ID的低32位从0位重新开始计数。
(5)新Leader通过事务ID和所有的Follower机器上的事务ID进行对比，确保数据同步。保证数据在所有的Follower上与之达成同步。旧Leader上新被提出的事务被抛弃。当数据达到同步，才将Follower服务器加入可用的Follower服务器列表。然后开始消息广播。
网友评论