Zookeeper系列（5）--ZAB协议，消息广播，崩溃恢复，数据同步

在前一篇中，写了Zookeeper的相关概念，以及节点、acl，watcher等机制，这一篇就写一下保证ZK集群高可用及数据一致性的底层实现算法：ZAB协议。

ZAB协议概述

在前面的文章中，介绍了经典的分布式数据一致性算法Paxos算法，但事实上zookeeper并没有采用完全的Paxos算法，而是采用了一种称为Zookeeper Atomic Broadcast(ZAB，zookeeper原子消息广播协议)。 ZAB 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性，同时其崩溃恢复过程也确保看zk集群的高可用性（HA）。

Zookeeper使用一个单一主进程来接收并处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器数据的状态变更以事务Proposal的形式广播到所有的副本进程上，并且ZAB协议能够保证一个全局的变更序列。

ZAB协议的核心是定义了对于那些会改变Zookeeper服务器数据状态的事务请求的处理方式。

Zookeeper 客户端会随机连接到 Zookeeper 集群的一个节点，如果是读请求，就直接从当前节点中读取数据；如果是写请求且当前节点不是leader，那么节点就会向 leader 提交事务，leader 会广播事务，只要有超过半数节点写入成功，该写请求就会被提交（类 2PC 协议）。

那么问题来了：

• 主从架构下，leader 崩溃，数据一致性怎么保证？
• 选举 leader 的时候，整个集群无法处理写请求的，如何快速进行 leader 选举？

所以zab协议重要的就是：1. 消息广播协议（leader想其他节点广播事务）  2. leader选举（快速选举过程fastleaderelection，集群刚启动时，leader崩溃或leader与集群中超过一半的节点断连后） 3. leader重新选举后，如何进行数据同步到一致状态

ZAB 中的节点有三种状态

• following：当前节点是跟随者，服从 leader 节点的命令
• leading：当前节点是 leader，