zookeeper-Leader选举-说明

ZAB 哪些成员身份

ZAB 支持 3 种成员身份（领导者、跟随者、观察者）

• 领导者 Leader）： 作为主（Primary）节点，在同一时间集群只会有一个领导者，所有的写请求都必须在领导者节点上执行。
• 跟随者 （Follower）：作为备份（Backup）节点， 集群可以有多个跟随者，它们会响应领导者的心跳，并参与领导者选举和提案提交的投票。跟随者可以直接处理并响应来自客户端的读请求，但对于写请求，跟随者需要将它转发给领导者处理。
• 观察者 Observer）：作为备份（Backup）节点，类似跟随者，但是没有投票权，也就是说，观察者不参与领导者选举和提案提交的投票。你可以对比着 Paxos 中的学习者来理解。

成员状态

有3种 成员但是有4种状态

  public enum ServerState {
        LOOKING, FOLLOWING, LEADING, OBSERVING;
    }

• LOOKING：选举状态，该状态下的节点认为当前集群中没有领导者，会发起领导者选举
• FOLLOWING ：跟随者状态，意味着当前节点是跟随者。
• LEADING ：领导者状态，意味着当前节点是领导者。
• OBSERVING： 观察者状态，意味着当前节点是观察者

假设投票信息的格式是<myid,zxid,proposedEpoch>

• myid 当前服务器在集群中的server.id
• zxid 当前服务器中的最大事务id
• 任期编号 节点提议的，领导者的任期编号

服务刚启动，没有事务，事务ID，为0 ，默认的领导者任期编号为0，
每次选举时，领导者任期编号+1
A，启动时，Follower myid 1,zxid -0， 提议领导者任期编号为1
B 启动时，Follower myid 2,zxid -0， 提议领导者任期编号为1

选举规则
每个节点会创建一张选票，这张选票是投给自己的，节点A、B 都“自告奋勇”推荐自己为领导者
A和B都会先给自己投票，，然后各自将选票发送给集群中所有节点，也就是说，A 发送给 A、B，B也发送给 B、A。
一般而言，节点会先接收到自己发送给自己的选票（因为不需要跨节点通讯，传输更快），

也就是说，B 会先收到来自 B 的选票，A 会先收到来自 A 的选票

为了选举出数据最完整的节点，每接收到一张投票都要进行 投票PK

• 优先检查任期编号（Epoch），任期编号大的节点作为领导者；
• 如果任期编号相同，比较事务标识符的最大值，值大的节点作为领导者；
• 如果事务标识符的最大值相同，比较集群 ID，集群 ID 大的节点作为领导者。

• 对于B 节点 ，由于A与B节点的任期编号相同，A与B的事务ID也相同，但B的myid与 A的myid大，正常保存投票就可以了
• A节点，由于myid比B的myid小，所以需要调整，A节点除了接收与保存投票信息外，还要更新自己的选票
  

更新后为 2,0,1，并再次发送选举给自己和B，也就是推举B为领导者

当A,B都接收来自A的选票后，因为选票为2，0，1 与B的本身提议的领导者相同，B当选领导者，都正常接收与保存选票即可。