ZAB协议

zookeeper 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面，zookeeper 并没有使用 Paxos ，而是采用ZAB 协议，它有两种基本模式，崩溃恢复模式和消息广播模式，ZAB 让整个 zookeeper 集群在两个模式之间转换，消息广播可以说是一个简化版本的 2PC，通过崩溃恢复解决了 2PC 的单点问题，通过队列解决了 2PC 的同步阻塞问题。而支持崩溃恢复后数据准确性的就是数据同步了，数据同步基于事务的 ZXID 的唯一性来保证，通过 + 1 操作可以辨别事务的先后顺序。基于该协议，zookeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

消息广播模式：ZAB 协议的消息广播过程使用的是一个原子广播协议，类似一个二阶段提交过程。对于客户端发送的写请求，全部由 leader 接收，leader 将请求封装成一个事务 proposal，将其发送给所有 follwer ，如果超过半数follwer 成功响应，则执行 commit 操作（先提交自己，再发送 commit 给所有 follwer）。

1.leader 在收到客户端请求后，会将这个请求封装成一个事务，并给这个事务分配一个全局递增的唯一 ID，称为事物ID（ZXID），ZAB 协议需要保证事务的顺序，因此必须将每一个事务按照 ZXID 进行先后排序然后处理。

2. 在 leader 和 follwer 之间还有一个消息队列，用来解耦他们之间的耦合，解除同步阻塞。

3. zookeeper集群中为保证任何所有进程能够有序的顺序执行，只能是 leader 服务器接受写请求，follower 服务器接受到客户端的写请求，则转发到 leader 服务器进行处理。

4. ZAP协议的二阶段提交过程中，移除了中断逻辑，所有的follow服务器要么正常反馈，要么就抛弃leader服务器提出的事物proposal。

崩溃恢复模式：解决leader崩溃带来的数据不一致问题。

ZAB定义了两个原则：

1. ZAB 协议确保那些已经在 leader 提交的事务最终会被所有服务器提交。
2. ZAB 协议确保丢弃那些只在 leader 提出，但没有提交的事务。

针对这个要求，如果让 Leader 选举算法能够保证新选举出来的 leader 服务器拥有集群总所有机器编号（即 ZXID 最大）的事务，那么就能够保证这个新选举出来的 leader 一定具有所有已经提交的提案。

数据同步：当崩溃恢复之后，需要在正式工作之前（接收客户端请求），Leader 服务器首先确认事务是否都已经被过半的 Follwer 提交了，即是否完成了数据同步。目的是为了保持数据一致。当所有的 Follwer 服务器都成功同步之后，Leader 会将这些服务器加入到可用服务器列表中。

在 ZAB 协议的事务编号 ZXID 设计中，ZXID 是一个 64 位的数字，其中低 32 位可以看作是一个简单的递增的计数器，针对客户端的每一个事务请求，leader 都会产生一个新的事务 Proposal 并对该计数器进行 + 1 操作。而高 32 位则代表了 leader 周期的编号，每当选举产生一个新的leader，就从这个leader服务器取出本地日志中最大事务 proposal 的 ZXID，并从该 ZXID 中解析出对应的 epoch 值，然后再对这个值加一，最为新的epoch。高 32 位代表了每代 Leader 的唯一性，低 32 代表了每代 Leader 中事务的唯一性。同时，也能让 Follwer 通过高 32 位识别不同的 Leader，简化了数据恢复流程。基于这样的策略：当 Follower 链接上 Leader 之后，Leader 服务器会根据自己服务器上最后被提交的 ZXID 和 Follower 上的 ZXID 进行比对，比对结果要么回滚，要么和 Leader 同步。