zookeeper使用zab协议来保持集群数据的一致性

zab协议可以认为是一种二段提交协议

主要由两部分组成：崩溃恢复和消息广播，具体过程为

选主 -> 数据同步 -> 广播

消息广播

消息广播阶段主要完成leader结点向follower结点同步日志，过程如下
1 client发起写请求

2 leader封装写请求为proposal，向follower预写请求

3 leader收到follower返回半数以上的预写请求确认，commit该日志

4 leader向客户端返回成功

5 follower同步leader已提交的日志

PS：只有leader能够处理写请求，follower收到写请求会重定向给leader

崩溃恢复

崩溃恢复阶段主要进行选主和数据同步

选主

zookeeper中节点有leader和follower两种角色

每个节点有四种状态：LOOKING，FOLLOWING, LEADING, OBSERVING

LOOKING：选主状态

FOLLOWING：following状态

LEADING：leading状态

OBSERVING：观察状态

PS: OBSERVING主要用于集群扩容，不再讨论范围

leader、follower之间通过心跳机制维护状态

当感知leader挂掉之后，follower进入LOOKING状态

follower生成选主请求，投自己一票，然后向其余follower节点发送选主请求，如果收到一半以上的成功回复，则竞选成功

选主请求主要由两部分数据组成：MYID和ZXID

MYID：配置的节点ID

ZXID：64位事务ID，低32位为递增计数，高32位为集群事务ID，依次递增

其他follower接收到选主请求后，会依次比较请求的ZXID和MYID，给数值大者投票

以5结点的集群的启动选主为例，依次启动1、2、3、4、5结点，3结点会成为leader

原因是启动时ZXID一致，3节点正好能够获取超过一般的票数，后续的4、5启动时发现3已经是leader

当完成选主之后，leader便进入数据同步阶段

数据同步

数据同步阶段主要工作是follower进行与leader之间的差异同步

考虑异常情况：

1 事务在leader上提交，且接收到follower的ACK，但leader发commit消息前崩溃

2 事务在leader上提出，leader崩溃

zab通过两个约束来保持一致性：

1 确保已经提交的日志必须被所有的follower提交

2 确保只丢弃未被leader提交的日志

从而，zab选举出的leader

1 不包含未提交的日志

leader必须都是已经提交了proposal的follower服务器节点

2 新leader含有最高的ZXID

数据同步阶段，leader将自身提交的最大事务ZXID发送给follower，follower根据leader的消息进行回退或者数据同步，保证与leader数据的一致