ZOOKEEPER进阶

集群个数：

　　2n+1，因为集群当宕机大于等于二分之一的机子时，集群选举会失败。故 2n+1台机器和3n台机器可靠性相同

Leader的作用：

　　为了实现各个节点数据的一致性，需要一个负责协调数据同步的操作，从而减小数据同步的复杂性

2PC（俩阶段提交）：

ZAB协议（支持崩溃恢复的原子广播协议）：

俩种基本模式：1. 崩溃恢复  2. 原子广播

当leader出现网络中断，宕机等情况时，ZAB协议就会进入恢复模式选取新leader，当 leader 服务器选举出来后，并且集群中有过半的机器和该 leader 节点完成数据同步后（同步指的是数据同步，用来保证集群中过半的机器能够和 leader 服务器的数据状态保持一致），ZAB 协议就会退出恢复模式，进入广播模式，此时leader正常工作，当启动新的机器时，该机器即进入数据恢复模式，与leader同步数据

消息广播的实现原理：

集群收到客户端的事务操作，将事务转发给leader，leader将消息赋予全局唯一的64位自增ID(ZXID),Leader将消息放入FIFO(First Input First Output)队列中，将带有zxid的消息作为一个Proposal（提议）发送给Follower，当 follower 接收到 proposal，先把 proposal 写到磁盘，写入成功以后再向 leader 回复一个 ack,只要超过半数节点反馈写入成功，leader发送commit消息，则这次事务操作提交（类似2PC）

崩溃恢复(数据恢复)：

当Leader发送无法连接，宕机等情况时导致leader失去了与过半follower的联系时，则会进入崩溃恢复模式。同时需要满足俩点：

1. 已被处理的消息不可以丢失

　　当leader在处理事务，且已经有节点收到了commit事务时，leader失去与其他follower的联系导致其他节点没有commit事务，此部分数据视为已处理消息，不可以丢失

2. 被丢弃的消息不可以再出现

　　当leader在处理事务，且再发送commit提交事务前，leader宕机，此消息视为被丢弃消息。在重新选取leader后，原leader被重启，重新加入集群，原leader中未被体提交的数据需要被删除

为了满足上述俩个要求，需要设计一个leader选举算法

leader需要拥有最大zxid（事务id），这使得leader保存了所有已经被commit的事务。

　　ZXID是一个64位自增的事务id,它包括前32位epoch编号，后32位消息计数器。每当zookeeper重新选举leader时，epoch就会+1，同时消息计数器重置为0。通过epoch编号，当老的leader重新接入时，可以通过epoch清楚旧的未commit得事务。

Leader选举：

结果，投票时，优先投票zxid最大，相同则投票myid最大的节点

过程：当节点启动时，节点进入LOOKING状态，处于观望状态，接下来就开始进行选主流程。起初每个节点会将自己作为leader投票，将自己的 zxid,myid,epoch发送给其他节点。当节点接受到其他节点的投票时，会判断其他节点投票的有效性（epoch是否为本轮编号，是否为LOOKING状态等），如有效，则通过比较 ZXID,MYID与自己的投票PK，将ZXID,MYID最大的重新投票。当leader选取好后，后加入的节点则作为follower（不考虑observer）

例：

1，2，3三台机子，epoch相等。按1,2,3启动，当1，2启动时，通过上述方式，选取2为leader，当3启动时，因leader已选取好，故自己作为follower