Zookeeper 如何保证分布式系统数据一致性
分布式架构出现后，越来越多的分布式系统会面临数据一致性的问题。目前，ZooKeeper 是在解决分布式数据一致性上最成熟稳定且被大规模应用的工业级解决方案。
ZooKeeper是一个分布式服务协调框架，基于ZooKeeper的数据结构、Watcher、选举机制等特点，可以实现数据的发布/订阅，软负载均衡，命名服务，统一配置管理，分布式锁，集群管理等等。
ZooKeeper 保证分布式系统数据一致性的核心算法就是 ZAB 协议（ZooKeeper Atomic Broadcast，原子消息广播协议）。
ZAB 协议
基于ZAB协议，Zookeeper实现了⼀种主备模式的系统架构来保持集群中各副本之间的数据的⼀致性，表现形式就是使⽤⼀个单⼀的主进程（Leader服务器）来接收并处理客户端的所有事务请求（写请求），并采⽤ZAB的原⼦⼴播协议，将服务器数据的状态变更为事务 Proposal的形式⼴播到所有的Follower进程中。
ZAB协议中的角色
Zookeeper 的集群中的服务器有 Leader 和 Follower ，但实际在 ZAB 协议中 Zookeeper 有三种角色，分别是 Leader、Folower、Observer：
- Leader(领导者)：负责整个Zookeeper 集群工作机制中的核心
- 事务请求的唯一调度和处理者，保证集群事务处理的顺序性
- 集群内部各服务器的调度者
- Follower(跟随者)：它是 Leader 的追随者
- 处理客户端的非事务请求，转发事务请求给 Leader 服务器
- 参与事务请求 Proposal 的投票
- 参与 Leader 选举投票
- Observer(观察者)：是 zookeeper 自 3.3.0 开始引入的一个角色，它不参与事务请求 Proposal 的投票，也不参与 Leader 选举投票，只提供非事务的服务（查询），通常在不影响集群事务处理能力的前提下提升集群的非事务处理能力
ZAB协议的两种模式
ZAB 协议的包括两种模式：消息广播、崩溃恢复。
消息广播模式
息广播类似于一个二阶段提交过程。Zookeeper使用一个单一的主进程来接收并处理客户端的所有事务请求，此消息广播协议基于FIFO队列，将需要广播的事务Proposal(提案)依次放入队列中，采用TCP通信。
广播过程：
- Leader发送事务提案(proposal)
针对客户端的事务请求，Leader服务器会为其生成对应的事务Proposal，并为该事务Proposal分配一个全局递增的唯一ZXID，ZXID由64位组成，其中高32位表示epoch(每个Leader的周期，年号)，低32位表示xid事务id，然后将事务Proposal发送给Follower进行投票表决。
每当选举产生一个新的Leader，就会取出此Leader的本地日志，从其记录的最大zxid中解析得到时代编号，然后对其加1，作为新的时代编号，再将低32位数字归零，从0开始重新生成zxid。 - Follower接收提案并响应ACK
Leader服务器为每个Follower服务器分配一个单独的队列，将需要广播的Proposal放到队列中，并根据FIFO策略进行小气发送。Follower接受到了事务Proposal请求后，会首先将其以事务日志的方式写入本地磁盘中，写入成功后向Leader返回ACK响应。 - Leader广播Commit消息
如果Leader收到半数以上的ACK响应后，就会广播一个Commit消息给Follower通知其进行事务提交，同时自身也会完成事务提交。
崩溃恢复模式
在消息广播的过程中，可能会出现Leader崩溃的场景，因此ZAB协议中添加了崩溃恢复模式来解决这个问题。
ZAB 中的节点有三种状态，伴随着的 Zab 协议消息广播和崩溃恢复两阶段之间的转换，节点状态也随之转换：
- folloing（当前节点是 Follower 节点）
- leading（当前节点是 Leader 节点）
- looking/election（当前节点处于选举状态）
选举过程：
- 各个节点变为 Looking 状态
Leader 宕机后，余下的 Follower 节点都会将自己的状态变更为 Looking（注意 Observer 不参与选举），然后开始进入 Leader 选举过程。 - 各个 Server 节点都会发出一个投票，参与选举
在第一次投票中，所有的 Server 都会投自己，然后各自将投票发送给集群中所有机器。 - 集群接收来自各个服务器的投票，开始处理投票和选举
首先选举 epoch 最大的，如果 epoch 相等，则选 zxid 最大的，若 epoch 和 zxid 都相等，则选择 server id 最大的。
在选举过程中，如果有节点获得超过半数的投票数，则会成为 Leader 节点，反之则重新投票选举。 - 选举成功，各节点的状态为 Leading 和 Following
数据同步
崩溃恢复完成选举以后，接下来的工作就是数据同步，在选举过程中，通过投票已经确认 Leader 节点是最大 Zxid 的节点，同步阶段就是利用 Leader 前一阶段获得的最新 Proposal 历史同步集群中所有的副本。
总结
ZAB 协议是 CAP 理论中 CP 的典型实现，其崩溃恢复阶段涉及到的 Leader 节点选举过程和数据同步选举完成后的数据同步过程都是对外不提供服务的，就是为了保证数据的强一致性牺牲了可用性。
