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 协议包括两个基本模式: 消息广播以及崩溃恢复 **
* 消息广播流程示意图如下:*
(图片来自从 Paxos 到 zk)
正如图中所示, 部署 zk 集群至少需要有三个节点, 否则 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 服务器列表然后开始消息广播
来源: https://www.cnblogs.com/wesleycheung/p/8546404.html