1、zk基础：
1.1、ZAB 协议
唯一leder保证了所有事务全局有序，follower 收到事务请求需要转发给leader
ZAB 协议定义的两种模式：崩溃恢复和消息传播。
恢复模式：集群启动、leader 崩溃（leader 与 follower 网络中断等）时 集群处于恢复模式，对外不可用；
消息广播：过半的follower 同步了leader的状态后，集群进入广播模式，此时新加入的节点自动进入广播模式，
1.2、协议详解：
消息广播
采用的原子广播协议，类似二阶段提交。
leader 收到事务请求后为该事务生成全局唯一事务ID(WZID) 产生事务 proposal， 并发送给 follower， follower 收到后恢复确认（即选票），leader 收到过半选票就向客户端 commit 事务成功；消息广播协议采用 TCP 通信；
如何保证消息的全局有序处理?
1、leader 为 每个 follower 分配一个 FIFO 队列， 每个事务proposal 都会放进队列，再发送给 follower 。
2、follower 收到事务后先将proposal 落盘到事务日志，然后返回leader ACK。
3、leader 收到过半数的 ACK 就发送commit 消息给follower 通知其进行事务提交，同时自己也提交事务。
ZAB 协议保证在leader 上提交的事务中最会被所有的服务器提交
ZAB 协议保证丢弃 只在leader 服务器被提出的事务
崩溃恢复
每个事务ID（ZXID）为64位，前32位是epoch，每次leader更换时会加1，后32是事务ID，每个事务递增当一个leader 在任期中提出一个事务Pn 后就崩溃时，follower 没有收到 Pn commit 消息，就不会commit 该事务。然后剩余的 commit 会重新选一个leader, 新任leader 事务ID 中的epoch 加1， 当旧的leader 重新加入集群后，发现自己的任期epoch 比现在的Qorum epoch 小，将自己设置为folloer, 同时，从现任leader 中同步数据时，会被要求删除Pn。
选举流程
1、启动时选举：
每个节点发起投票（SID,ZXID），计票阶段先判断选举周期epoch，对同一周期里的选票，由于服务器是刚启动的，此时ZXID 相同，SID 大的为leader。后续加入的节点，就直接进入FOLLOING状态了。
2、运行时选举：
运行时leader 崩溃，follower 发起选举，此时ZXID 可能不同，ZXID 大的为leader。
集群状态
集群启动时处于LOOKING 状态，选举完成后folloer 处于 FOLLOWING状态，leader 处于 LEADING 状态，并对外提供服务。
leader 与 follower 心跳检测超时，或TCP 断开链接，leader 会 进入LOOKING状态，剩下的follower 会选出新的leader。
心跳机制
leader 和 follower 之间用心跳机制判断对方是否在线
来源：CSDN
作者：acethan
链接：https://blog.csdn.net/acethan/article/details/104844672