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的提交和丢弃工作这一步