首先 zookeeper 的核心是原子广播，这个机制保证了各个 server 之间的同步，而实现这个机制的协议叫做 ZAB 协议。ZAB 协议是为 zookeeper 专门设计的一种支持故障恢复的消息广播协议。
ZAB 协议只允许有一个主进程接收客户事务请求并处理，也就是 Leader。当 Leader 收到请求后，由于 leader 会为每一个 follow 创建一个队列，所以会将该事务放入响应队列中，并将那些没有被各 follow 服务器同步的事务转化为 Proposal 消息的形式发送给 follow 服务器，按顺序来处理事务，保证事务的顺序性。之后 leader 会在队列中顺序向其他节点广播该提案，follow 收到后会将其以事务的形式写入到本地日志中，并向 leader 发送反馈 ack 确认。leader 会等待其他 follow 的回复，当收到一半以上的 follow 响应时，leader 会向其他节点发送 commit 消息，同时提交该提案。
ZAB 有两种模式，分别是故障恢复模式和消息广播模式。当系统启动或者 leader 服务器出现故障等现象时，会进入故障恢复模式，这是会开启 leader 新一轮的选举，选举产生的准 leader 会与超过一半的 follow 进行同步，使数据一致。
当同步结束后，退出恢复模式，进入消息广播模式。当一台遵从 ZAB 协议的服务器启动后，如果检测到有 leader 在广播消息，会自动进入故障恢复模式，当其完成与 leader 的同步之后，才会进入消息广播模式；如果集群中的非 leader 节点收到客户端事务请求，非 leader 节点会将请求发送给 leader 服务器。
在故障恢复模式的时候，ZAB 协议需要保证两个地方，第一个是 ZAB 协议需要保证已经被 leader 提交的事务最终被所有的机器提交，第二个是需要保证必须要丢弃掉那些只在 leader 上提交的事务。选举时如果选择 ZXID 最大的节点则可以保证这两点问题。
leader 重新选举的条件是当 leader 宕机或发生故障，集群中少于一半的节点与当前 leader 保持连接。
简述 ZAB 协议（zookeeper Atomic Broadcast ）_Java 大数据运动猿的博客 - CSDN 博客
