Zookeeper Leader Election

    Master election is a common application scenario in distributed systems. In a distributed system, the Master is often used to coordinate other system units in the cluster and has the right to decide the state change of the distributed system.

    For example, in read-write separation applications, the client's write request is often handled by the master (such as MySQL distributed cluster). In other scenarios, the master often handles some complex logic and synchronizes the processing results to other in the cluster. System unit (such as redis, one master and three slaves).

 

    Master election is the most typical application scenario of zookeeper. In the zookeeper cluster, there are three types of server roles: leader/follower/observer. Master election is the process of electing the main leader.

 

Cluster role introduction:

Leader:

           It is the core of the entire zookeeper cluster working mechanism.

           The main work:

                       The only scheduler and processor of transaction requests to ensure the orderliness of cluster transaction processing.

                       The scheduler of each server in the cluster.

 

Follower:

            is a follower of the zookeeper cluster state

           The main work:

                       Process client non-transactional requests and forward transactional requests to the Leader server

                       Participate in the vote of the transaction request proposal

                       Participate in the Leader Election Voting

 

 

Observer:

             It is a brand new server role introduced after version 3.3.0.

             Observe the latest state changes of the zookeeper cluster and synchronize these state changes in.

             It can be processed for non-transactional requests. For transactional requests, it is forwarded to the Leader server for processing.

              do not participate in any form of voting

 

Leader election steps:

   1. Initialize Leader election

             First, each server votes for itself

            然后,根据zoo.cfg中的配置,创建相应leader选举算法。默认提供三种:                                     LeaderElection/AuthFastLeaderElection/FastLeaderElection

            但是3.4.0之后,只有一个算法:FastLeaderElection

 

           同时创建选举所需的网络I/O层,同时启动leader选举端口的监听。

 

  2、注册JMX服务

  3、检测当前服务器状态

           正常情况下:zookeeper服务器状态在LOOKING、LEADING和FOLLOWING/OBSERVING之间的切换。

            在LOOKING状态下才可以选举

  •             LOOKING:寻找Leader状态。
  •             FOLLOWING:跟随者状态,代表该服务器角色是Follower
  •             LEADING:领导者状态,代表该服务器角色是Leader
  •             OBSERVING:观察者状态,代表该服务器角色是Observer

 

  4、Leader选举

            简而言之,就是哪个机器处理的数据越新,就越可能成为Leader

            SID:服务器ID,也就是myid

           ZXID:事务ID,用来唯一标识一次服务器状态的变更。

           epoch:当前服务器的currentEpoch

 

           如果集群中所有的机器处理的ZXID一致,那么SID最大的服务器成为Leader。

 

 

应用时期

 

注:1台机器是无法完成选举的,至少有两台才行

 

服务器启动时期的Leader选举

 

1、每个server会发出一个投票

           每次投票包含的最基本的元素包括:myid和ZXID。

           一开始每台服务器都给自己投一票:(1,0);(2,0)

2、接收来自各个服务器的投票

3、处理投票           

         针对每个投票,服务器都要将别人的投票和自己的PK:

  •     优先检查ZXID,ZXID比较大的服务器优先作为Leader。
  •     如果ZXID相同,就比较myid,myid大的作为Leader服务器。

 

4、统计投票

5、确定leader之后,就改变自己服务器的状态。

 

 

服务器运行期间的Leader选举

 

1、变更状态

               变成LOOKING状态

2、每个Server会发出一个投票

             生成各自的投票信息(myid,ZXID)

3、接收来自各个服务器的投票

4、处理投票

5、统计投票

6、改变服务器状态

 

 

 

Leader 选举是zookeeper中最重要的技术之一,也是保证分布式数据一致性的关键。

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325635623&siteId=291194637