【Zookeeper】集群模式启动源码解析

状态ServerState:

• LOOKING:（启动的时候默认状态）集群里没有选举出Leader的时候，所有节点都是这个状态
• FOLLOWING：Follower的状态
• LEADING：被选举成Leader的状态
• OBSERVING：obeserve的状态

三个端口：
三种端口分别用来进行三种通信：接收客户端的命令（Netty/NIO）、进行选举、节点之间互相传数据

选举Leader流程

选举Leader流程

启动的时候每台机器的状态都是LOOKING状态，这时就是选举Leader。

• 当机器是LOOKING状态，会先创建一个选票（myid,zxid,选举周期…）发送给其他机器
• 自己也会收到其他发来的选票。 将自己和收来的选票进行pk，规则是先比较选举周期、再比较zxid，最后比较myid，谁大就把自己的选票更新成获胜的选票，且会把更新后的选票发给其他所有的。
• 将所有收来的选票都放到set里，根据过半机制选出Leader，会把选出的Leader的状态改为leading，其他改为following。
• 已经选出Leader后对于新加入的机器而言的状态为LOOKING状态，它会接收到之前的获胜选票，这时pk由于新加入的机器选举周期（1）会比获胜选票的周期小，所以它就会把自己的状态更新为following。
• 由于机器之间会建立通信用来同步数据，Leader会向所有的机器（Followers和Observers）发送数据，这些机器会一直处于接收状态，当一段时间接收不到Leader发来的数据，就会将自己的状态改为LOOKING，这时又会开始选举新的Leader。

pk逻辑，即从recvqueue中拿出来选票后做的事

Notification n=recvqueue.poll(notTimeout,TimeUnit.MILLISECONDS)

• n==null 第一次启动的时候是没有选票的这时去跟需要发送选票的机器建立Socket连接
• n不为空，即拿到别人发来的选票。判断发来选票的机器的状态n.state
  • 发来选票的机器状态为LOOKING

    • 接收到的选票周期大于自己的周期

    • 接收到的选票周期等于自己的周期

    • 接收到的选票周期小于自己的周期

  • 发来选票的机器状态为LEADING或FOLLOWING
    这种情况就是已经选出Leader