Zookeeper-集群崩溃恢复

1. zookeeper 的一致性，为了防止单机挂掉，zookeeper维护了一个集群，实现自身的高可用

1.1 Zookeeper 集群是一主多从结构

1.2 在更新数据时，首先更新到主节点（这里的节点时指服务器，不是Znode），再同步到从节点。

1.3 再读取数据时，直接读取任意从节点

1.4 为了保证主从节点的数据一致性，Zookeeper采用了ZAB协议，这种协议非常类似于一致性算法 Paxos和Raft.

2. 什么是ZAB？

2.1 Zookeeper Automic Broadcast,有效的解决了Zookeeper集群崩溃恢复，以及主从同步数据的问题。

2.2 ZAB协议定义的三种节点状态

Looking-选举状态

Following-从节点

Leader-主节点

2.3 最大ZXID：节点本地的最新事务编码，包含epoch和计数两部分。

2.4 ZAB的崩溃恢复

　　假如Zookeeper 当前的主节点挂掉了，集群会进行崩溃恢复，分三个阶段：

2.4.1 Leader election 选举状态。此时季军中的节点处于Looking状态，向其他节点发起投票，投票当中包含自己的服务器ID和最新的事务ID（ZXID)

　　接下来，节点会用自身的ZXID和从其他节点接收到的ZXID做比较，如果发现别人家的ZXID比自己的大，也就是数据比自己新，那么久重新发起投票，投票给目前已知最大的ZXID所属节点。

　　每次投票后，服务器都会统计投票数量，判断是否有某个节点但得到半数以上的投票，如果存在这样的节点，该节点将会成为准Leader，状态变为Leader,其他系欸但状态变为Following。

2.4.2 Discover 发现阶段，用于从节点中发现最新的ZXID和事务日志，问：既然Leader被选为主节点，已经是集群里最新数据了，为什么还要从节点中寻找最新事务呢？

　　这是为了防止某些意外情况，比如因网络原因再上一阶段产生多个Leader的情况。

　　所以该阶段。Leader接受所有Follower发来的各自最新的epoch值，Leader从中选出最大的epoch，基于此值加1，生成新的epoch分发给各个Follower。

各个Follower收到全新的epoch后，返回ACK给Leader，带上各自最大的ZXID和历史事务日志。Leader选出最大的ZXID，并更新自身历史日志。

2.4.3 Sysnchronization 同步阶段，把Leader 刚才收集得到的最新历史事务日志，同步给集群中所有的Follower，只有当半数Follower同步成功，这个准Leader才能成为正式的Leader，故障恢复正式完成。

2.5 ZAB数据写入

2.5.1 Broadcast，Zookeeper常规情况下更新数据的时候，由Leader广播所有的Follower，其过程如下：

　　1. 客户端发出写入的数据请求给任意Follower

　　2. Follower把写入数据请求转发给Leader

　　3. Leader采用二阶段提交方式，先发送Propose广播给Follower

　　4. Follower接收到Propose消息，写入日志成功后，返回ACK消息给Leader。

　　5. Leader接到半数以上ACK消息，返回成功给客户端，并且广播Commit请求给Follower