zookeeper zab协议

https://blog.csdn.net/liuxiaohui1/article/details/107466159

 

一、zab协议消息广播模式

消息广播的实现原理

    消息广播存在事务处理过程中（改良版本的2pc）：

        1. Leader 接收到消息请求后，将消息赋予一个全局唯一的64 位自增 id，叫：zxid，通过 zxid 的大小比较既可以实

        现因果有序这个特征；

        2. Leader 为每个 follower 准备了一个 FIFO 队列（通过 TCP协议来实现，以实现了全局有序这一个特点）将带有 zxid的消息作为一个提案（proposal）分发给所有的 follower；

        3. 当 follower 接收到 proposal，先把 proposal 写到磁盘，写入成功以后再向 leader 回复一个 ack

        4. 当 leader 接收到合法数量（超过半数节点）的 ACK 后，leader 就会向这些 follower 发送 commit 命令，同时会在本地执行该消息

        5. 当 follower 收到消息的 commit 命令以后，会提交该消息

 

二、zab协议崩溃恢复模式

1、刚启动集群

当某个节点启动后，会与其他节点两两之间交换数据，也就是两两之间根据事务id和myid大小投票，谁大投谁。谁先得到半数以上的票，则先成为leader。如果交换数据过程中发现已经选好leader(下面例子的服务器4和5)，那么直接当小弟，与leader同步数据。

 

以下为例子：

假设目前有五台服务器，每台服务器均没有数据，编号分别是 1，2，3，4，5，按照编号一次启动他们：

服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking。

服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。

服务器3启动，给自己投票，同时与之前启动的服务器1,2依次交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。

服务器4启动，给自己投票，同时与之前启动的服务器1,2,3依次交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。

服务器5启动，后面的逻辑同服务器4成为小弟。

这样，服务器3成为了 leader !

基于上面的选举流程，试想如果是启动顺序按照服务器 5，4，3，2，1 ，谁会是 leader 呢？

ps：这里的编号指的是：myid 文件里对应的编号。

答案是：服务器 5

 

2、集群运行中，中途leader宕机了

leader故障后，其他follower都参与投票，与上面1的投票类似，也是各自两两之间交换数据，比较事务id和myid，谁大就投谁。。如果交换数据过程中发现已经选好leader，那么直接当小弟，与leader同步数据。