Zookeeper中的分布式一致性协议ZAB

1、Zab 协议

在分布式系统中实现一致性是件困难的事。

Paxos 算法可以较好的解决分布式系统的一致性，但由于复杂，在实际工程上不是很合适。

ZAB（ZooKeeper Atomic Broadcast ） 协议借鉴了 Paxos 的思想，ZAB在Paxos算法上做了重要改造，和Paxos有着明显的不同，以满足工程上的实际需求。

有序性是 Zab 协议与 Paxos 协议的一个核心区别。

Zab 的有序性主要表现在两个方面：

全局有序：如果消息 a 在消息 b 之前被投递，那么在任何一台服务器，消息 a都会在消息 b 之前被投递。

因果有序：如果消息 a 在消息 b 之前发生（a 导致了 b），并被一起发送，则 a 始终在 b 之前被执行。

2、Zab 协议分为两部分

广播（boardcast）：Zab 协议中，所有的写请求都由 leader 来处理。正常工作状态下，leader 接收请求并通过广播协议来处理。

恢复（recovery）：当服务初次启动，或者 leader 节点挂了，系统就会进入恢复模式，直到选出了有合法数量 follower 的新 leader，然后新 leader 负责将整个系统同步到最新状态

2.1 广播（boardcast）

广播的过程实际上是一个简化的二阶段提交过程：

1.Client会向一个Follower提交一个写请求

2.Follower将写请求发送给Leader

3.Leader接收到写请求后，将消息赋予一个全局唯一zxid，通过 zxid 的大小比较即可实现因果有序这一特性。Leader 通过每个 follower对应的队列将带有 zxid 的消息作为一个提案（proposal）广播分发给所有 follower。消息体类似（zxid-0,data）形式。

4.当 follower 接收到 proposal，先将 proposal 写到硬盘，写硬盘成功后再向 leader 回一个 ACK。

5.当 leader 接收到超过半数的 ACKs 后，leader 就向所有 follower 广播发送 COMMIT 提交命令，同时会在本地执行该消息。当 follower 收到消息的 COMMIT 命令时，就会执行提交。

6.（接收Client请求的）Follower将写请求的结果返回给Client。

2.2 恢复（recovery）

由于之前讲的 Zab 协议的广播部分不能处理 leader 挂掉的情况，Zab 协议引入了恢复模式来处理这一问题。为了使 leader 挂了后系统能正常工作，需要解决以下两个问题：

已经被处理的消息不能丢

被丢弃的消息不能再次出现

让Leader选举算法能够保证新选举出来的Leader服务器拥有集群中所有机器最高编号(ZXID最大)的事务Proposal，就可以保证这个新选举出来的Leader一定具有所有已经提交的提案。更为重要的是，如果让具有最高编号事务Proposal的机器来成为Leader，就可以省去Leader服务器检查Proposa的提交和丢弃工作这一步