分布式理论篇：zab协议

1. ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）

上图显示了 Zookeeper 如何处理集群中的数据。所有客户端写入数据都是写入到 主进程（称为 Leader）中，然后，由 Leader 复制到备份进程（称为 Follower）中。从而保证数据一致性。

复制过程类似 2PC，但ZAB 只需要 Follower 有一半以上返回 Ack 信息就可以执行提交，大大减小了同步阻塞。也提高了可用性。

还有一些细节：

1. Leader 在收到客户端请求之后，会将这个请求封装成一个事务，并给这个事务分配一个全局递增的唯一 ID，称为事务ID（ZXID），ZAB 兮协议需要保证事务的顺序，因此必须将每一个事务按照 ZXID 进行先后排序然后处理。

2. 在 Leader 和 Follwer 之间还有一个消息队列，用来解耦他们之间的耦合，解除同步阻塞。

3. zookeeper集群中为保证任何所有进程能够有序的顺序执行，只能是 Leader 服务器接受写请求，即使是 Follower 服务器接受到客户端的请求，也会转发到 Leader 服务器进行处理。

4. 实际上，这是一种简化版本的 2PC，不能解决单点问题。等会我们会讲述 ZAB 如何解决单点问题（即 Leader 崩溃问题）。

崩溃恢复

在ZooKeeper集群正常运行过程中，一旦选出一个Leader，那么所有服务器的集群角色一般不会再发生变化。也就是说，Leader服务器将一直作为集群的Leader，即使集群中有非Leader节点挂了或是有新机器加入集群也不会影响 Leader。但是一旦Leader 所在的机器挂了，那么整个集群将暂时无法对外服务，而是进入新一轮的Leader选举。服务器运行期间的Leader 选举和启动时期的Leader 选举基本过程是一致的。我们假设当前正在运行的ZooKeeper服务器由3台机器组成，分别是 Server1、Server2和Server3，当前的Leader是Server2。假设在某一个瞬间，Leader挂了，这个时候便开始了Leader 选举。

变更状态

当 Leader 挂了之后，余下的非Observer服务器（不参与选举的服务节点）都会将自己的服务器状态变更为LOOKING，然后开始进入Leader选举流程。 

每个Server会发出一个投票

在这个过程中，需要生成投票信息（myid，ZXID）。因为是运行期间，因此每个服务器上的ZXID可能不同，我们假定Server1的ZXID为123，而Server3的ZXID为 122。在第一轮投票中，Server1和Server3都会投自己，即分别产生投票（1，123）和（3，122），然后各自将这个投票发给集群中所有机器。

接收来自各个服务器的投票

处理投票

对于投票的处理，和上面提到的服务器启动期间的处理规则是一致的。在这个例子里面，由于Serverl的ZXID为123，Server3的ZXID为122，那么显然，Serverl会成为Leader。

统计投票

改变服务器状态