Zookeeper（三）ZAB协议的两种基本模式：崩溃恢复和广播消息

ZAB协议的两种基本模式：崩溃恢复和广播消息

1.崩溃恢复

Leader服务器选举
ZooKeeper会有两种情况下进行Leader选举
1）集群初始化
2）集群的Leader失去连接，需要重新选举一个新的Leader。

服务器进行选举时投票主要包含两个信息：推举服务器的唯一标识和事务编号：服务器的ID和ZXID。
服务器进行投票时发送消息自己的投票（ID,ZXID）到集群中的其他服务器，服务器在收到其他服务器发来的投票时，会和自己的投票进行比较，
首先，比较事务ID，
如果其他服务器的ZXID大于自己的ZXID，则更新自己的投票，自己的投票更新为其他服务器的投票（即收到的服务器发来的投票），并将的投票投出来集群中另外的服务器；
如果其他服务器的ZXID小于自己的ZXID，不用更新自己投票，保留自己原来的投票；
如果其他服务器的ZXID与自己的ZXID相等，则比较服务器ID的大小，如果ID比自己的ID小，则保留自己的投票；如果ID比自己的ID大，则更新自己的投票为其他服务器的投票（即收到的服务器发来的投票）；

当服务器收到的投票推举某个服务器为Leader的票数大于集群的节点一半数时，则该服务器就被选举为Leader，
该服务器会修改自己的状态为LEADING，其他服务器也会修改自己的状态为FOLLOWING。

投票对象：
org.apache.zookeeper.server.quorum.Vote{

    final private long id;    //服务器的id，群集模式每个服务器都有个配置文件myid
    final private long zxid;    //服务器的事务id
    final private long electionEpoch;   //表明投票是哪个轮次的，每次发起Leader选举的投票轮次都会在原来的轮次上加1，以此来区别投票是在同一投票轮次的。
    final private long peerEpoch;  //被推举的Leader的epoch
    inal private ServerState state; //服务器的状态，默认是寻找Leader的状态：ServerState.LOOKING，服务器的状态查看下面的ServerState类

}

服务器状态：
public enum ServerState {
        LOOKING, FOLLOWING, LEADING, OBSERVING;
}

2.广播消息

数据更新（事务请求）
客户端每发送一个更新请求，ZooKeeper都会生成一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序，
这个唯一编号就是事务ID(ZXID)，只有更新请求才算是事务请求。
为保证按照事务的ZXID先后顺序来处理，Leader服务器会分别为每个Follower服务器创建一个队列，并将事务的先后顺序放入队列中，
并按照FIFO的策略进行消息发送。收到需要处理的事务后，Follower服务器会首先以及事务日志的形式写入服务器的磁盘中，写入成功后
会向Leader服务器发送ACK响应。当Leader服务器收到超过一半的Follower服务器的ACK响应后，会向所有Follower服务器广播Commit消息，
收到Commit消息的Follower服务器也会完成对事务的提交。
如果接收到事务请求的是Follower服务器，它会将请求转发给Leader服务器处理。