浅谈Zookeeper【三】ZK中Leader选举算法

一、前言

前面已经介绍过Zookeeper的基础知识以及ZAB协议的一些概念，其中ZAB协议中关键性的发现步骤，也就是Leader选举机制是如何完成的，在这里简单介绍一下。

二、Leader选举基本概念

集群服务节点状态 State：

1. LOOKING：寻找Leader节点状态，该状态下无Leader节点，触发Leader选举。
2. FOLLOWING：跟随者状态，表明该节点为Follower。
3. LEADING：领导状态，表明该节点为Leader节点。
4. OBSERVING：观察者状态，表明该节点为observer节点。

关于各个节点的角色，在之前ZAB协议中已经介绍，这里不过多介绍。

选票模型 Vote

sid： ServerID表明为被推举的Leader的唯一标识，等同于MyId。

zxid： 表明被推举的Leader事务ID，也就是服务提供期间内，执行数据更新事务操作的自增ID。

electionEpoch： 逻辑时钟，表明为一次选举的周期的id，每次新的选举该值自增+1，用来判断选举投票是否为同一选举轮次。

peerEpoch： 被推举Leader节点的选举轮次Epoch。

state： 当前服务节点的状态

选举网络通信管理器 QuorumCnxManager

每台机器在启动时，都会创建一个QuorumCnxManager来负责管理节点之间的选举投票通信。
QuorumCnxManager内部维护了一系列队列用来管理待发送的消息和收到的消息以及消息的发送器，并且负责管理与其他所有节点通信连接（socket）。

QuorumCnxManager维护的队列与集合：
1、消息发送队列（queueSendMap）：为其他所有节点分别维护一个消息发送队列，队列之间互不影响。
2、消息接受队列（recvQueue）：一个统一的消息接收队列，负责保存接收到的消息。
3、发送器集合（senderWorkerMap）： 为其他节点分配一个消息发送器，负责消息的发送。