ZAB(Zookeeper Atomic Broadcast)算法

ZAB算法

原子广播协议
Leading: 当前节点为集群 Leader，负责协调事务
Following: 当前节点为 Follower 在 Leader 协调下执行事务
Looking: 集群没有正在运行的 Leader, 正处于选举过程
Observing: 节点跟随 Leader 保存系统最新的状态提供读服务，但不参与选举和事务投票
Observing该状态不会不参与事务和选举，因此下文中只会描述前三种状态

ZAB协议存在两种工作模式:

广播模式: 当集群正常运行过程中，Leader 使用广播模式保证各 Follower 节点的一致性
恢复模式: 集群启动或 Leader 崩溃时系统进入恢复模式，选举 Leader 并将集群中各节点的数据同步到最新状态
Zookeeper 集群中每个节点都会存储系统数据的完整副本，可以独立处理读请求。

当 Follower 收到写请求时会将其转发给 Leader, Leader 为每个写请求分配唯一的全局有序的事务ID(Zookeeper Transaction Id, ZXID)。

Leader 在广播模式下协调各 Follower 完成事务，并保证集群更新到一致的状态。

一致性保证

ZAB协议保证集群的顺序一致性而不保证强一致性。

即 Leader 依次完成两个事务 A、B 时，不能保证所有 Follower 立即更新到最新状态(不保证强一致性); 只保证所有 Follower 一定时间内会同步到最新状态(保证最终一致性)，且任意 Follower 都认为事务A先于事务B完成，不会乱序(保证全局顺序一致性)。

此外，ZAB协议保证来自同一个 Follower 的两个事务 A、B 按照 Follower 发出请求的顺序(而非 Leader 收到请求的顺序)依次执行，不会出现乱序。即保证任意客户端写请求的一致性。

ZXID

ZXID 是 Zookeeper 集群中事务的唯一标识，保证全局有序。

ZXID 是一个 64 位整数, 高32位为周期号(epoch), 每个 Leader 被选举后都会增加 epoch 与上任 Leader 区分。低32位是 Leader 开始事务时分配的递增编号。

ZXID 中的 epoch 可以保证 Leader 崩溃重新选举后被丢弃的事务不会继续执行。

1.leader的选举过程

选举的优先级 epoch> counter > SID
ZAB集群在启动过程中，节点的启动顺序有快有慢，SID越小一般启动越快，如SID为0的节点会率先启动，所有的节点在启动的时候他的状态都是locking状态，S0启动时会先给自己投一票，然后该节点发起拉票让其他节点投票给他，如果此时S1节点起来了，经过对比两种额的ZXID值相同，但自己的SID比S0的大，因此S1会拒绝给S0投票，同时他也会要求S0将赞成票投给自己，也会跟其他节点发送信息让他们把赞成票投给自己，此时仅有S0，S1节点因此只有S1只有两票 ，然后S2节点启动了，S2节点也会拒绝给S0,S1节点投票，S2会拿到3票且S2超过半数可以成为leader，S2会把自己的epoch节点加一，且同步给S0,S1两个follower节点，此时S3，S4节点启动了，此时已存在leader节点，S3，S4会把赞成票给S2，并自动成为follower节点。S2节点会不断的向其他节点发送心跳。并将epoch编号发送给新加入集群的follower节点。

2.原子广播阶段

集群存在两个健康节点，其中S2是leader，S2向本地写入了3条proposal，此时的proposal是未提交的状态，每条proposal存在一个唯一的编号，这个编号是ZXID,这个ZXID是由两部分组成，一部分是epoch编号（表示的是leader的任期编号）另一部分是counter（表示的是索引的信息，每增加一个proposal序号值就会加1，序号是单调递增的），leader会以事务日志的形式写到硬盘上，然后会广播日志给其他的follower节点，如S1节点写到硬盘后，S1节点会发送收到的信息并返回Ack反馈信息给S2节点告诉他写入成功，并且会向其他节点复制另外的日志信息，顺序的去复制，发送一条响应一条，日志超过半数节点写入磁盘后 leader节点会提交 之前均为未提交状态。并在提交后给follower节点告知可以提交消息并把下一条消息提供给follower节点，依次进行这个过程。此过程相当于leader节点维护了一个先进先出的队列，使用队列的形式来保障follower节点消息的有序性。

3.新leader 提交前任leader未提交的proposal

leader节点S2写入第4条消息，同时将第4条消息复制给了S1，此时S2宕机了。根据选举规则，S1拥有最大的SID，因此S1成为新的leader节点，S1会将自己的epoch值加1，新Leader会把前任Leader未提交的索引为4的消息广播出去，当有半数以上的follower节点向leader节点反馈收到信息后 leader节点会将日志节点的proposal修改为已提交，leader节点也会告知其他的follower节点将自己的变为已提交状态。ZAB算法规定新的leader节点只有先将前任leader节点未提交的信息提交后才能生成自己任期内的消息。

4.新leader 覆盖前任leader未提交的proposal

索引位置为6的leader写入了索引位置为6的消息，并把该消息复制给了S0，此时S1宕机了，为选出leader时 S0也宕机了，后续其他节点因为epoch节点相同，S4的SID最大因此S4成为leader节点 但是S4不存在index为6的消息因此S4会广播自己任期的proposal，先生成proposal并同步S2，S3。 S0，S1活过来后，他们会以follower的形式加入集群，且index为6的节点消息会回退且S4新生成的proposal会同步过去将之前的消息覆盖。