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服务器处理。
Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐