Zookeeper-ZAB协议

ZK集群中角色

image.png

Leader

• 提供数据读和写能力
• 负责集群写请求的协调
• 同步数据到follower
• 参与选举

Follower

• 提供数据读的能力
• 同步leader数据
• 转发写请求到leader节点
• 参与选举

ObServer

• 提供数据读能力
• 不参与选举

ZAB保证数据的一致性

leader的处理过程

• 集群中所有的事务请求转发到leader节点
• leader节点生成全局事务Zxid，广播事务到所有follower节点
• follower接收到广播并返回ACK
• leader接受到过半节点ACK，则广播提出commit
• 响应事务请求到客户端

ZAB协议保证了所有的请求有序性

• 全局单调递增的事务id（zxid），zxid为64位数字。
• zxid低32位为计数器，每产生一个事务请求，服务器进行加1操作。
• zxid高32位为leader选举朝代（epoch），每次选举产生一个新leader节点，就会获取日志中最大的zxid，解析其epoch值，进行加1操作，并将低32位置零，生成新的zxid。

ZAB协议崩溃恢复模式特点
leader节点宕机/或者选举阶段得不到半数节点的反馈，则进入崩溃恢复阶段。

• ZAB协议如果一个propose事务请求在一个节点上处理成功，那么应该所有节点都处理成功。
• ZAB协议确保leader节点上提交的事务请求，已经commit的请求，最终在所有服务器提交。
• ZAB协议确保只丢失在leader节点崩溃阶段收到的事务请求，还没commit。

ZAB协议的数据同步

• leader节点同步过程逐条发送follower节点未同步的数据，并紧接着发送一个commit消息，表示事务已被提交。
• follower节点同步完成后leader节点才会将节点标记为可用。
• leader节点选举出来后，需等待follower节点同步leader节点数据，当超过半数节点完成同步，集群对外提供服务。

结合ZAB有序性及崩溃模式的约定，当崩溃的节点从leader节点变为follower节点后，leader节点会更具自身服务器上已提交的最后的proposal信息与follower节点上的proposal对比，发现follower有上一个朝代的proposal不一致，leader节点要求follower节点回退到leader节点proposal，即已被半数节点提交的事务请求。

leader选举
选举算法的要求

• leader节点拥有最高zxid
• 超过半数节点同意

选举过程的选票信息：

• 服务器id，myid，集群配置时分配的服务器唯一id。
• zxid，在服务器最大的事务id
• 逻辑时钟，投票轮次的技术。选举阶段节点超过一定时间，没有收到过半节点的反馈，且未选举出leader节点则进入下一轮投票。
• 选举的节点状态
  • Looking：竞选状态。
  • Following：随从状态，同步leader节点，参与选举。
  • Observing：观察状态，同步leader节点，不参与选举。
  • Leading：领导者状态。

选举的过程：

• 每个服务实例均发起选举自己为leader节点的选票
• 收到其他节点的选票信息，比较事务id是否比自己最新的事务id大，大则需改选票，投他一票。小则不投。相等则比较服务器id，选myid较大者。
• 收到其他节点的选票后，判断是否超过半数选票指向同一个节点，是则选为leader，否则发起下一轮选举。

zk集群节点数为什么建议单数

ZK集群的容错约定宕机的数量必须小于集群剩下的可用节点数。即允许宕机节点<n/2。那么如果部署4个节点的集群，则允许宕机数为1（1<4/2）。如果部署3个节点的集群，则允许宕机个数为1（1<3/2）。对于这两个部署方案，同样允许宕机的数量都为1，那么使用3台服务器，比使用4台服务器节省资源。

---

公众号：

qr.jpg