Leader Election

一、zookepper Leader Election 主要有两种方法:

(1)抢注Leader节点-----非公平模式

(2)先到先得,后者监听前者-----公平模式

(1)抢注Leader节点-----非公平模式

1.创建Leader父节点,如/chroot,并将其设置为persist持久节点;

2.各客户端通过在/chroot下创建Leader节点,例如/chroot/Leader,来竞争Leader,该节点被设置为ephemeral临时节点;

3.若某客户端创建Leader节点成功,则该客户端成功竞选为Leader;

4.若某客户端创建Leader失败,则竞选Leader失败,在/chroot/Leader节点上注册exist的watch监听,一旦该节点被删除则获得通知;

5.Leader客户端可通过删除Leader节点来放弃Leader;

6.如果Leader宕机,由于Leader节点被设置为ephemeral临时节点,Leader节点会被自行删除,而其他节点由于在Leader节点上注册了watch,故可得到通知,参加下一轮的Leader竞选,从而保证了客户端以Leader角色工作;

(2)先到先得,后者监听前者-----公平模式

1.创建Leader父节点,如/chroot,并将其设置为persist持久节点;

2. 各客户端通过在/chroot下创建Leader节点,如/chroot/Leader,来竞争Leader,该节点被设置为ephemeral_sequential临时顺序节点;

3.客户端通过getChildren方法获得/chroot/下的所有子节点,如果其注册的节点ID在所有的子节点ID中是最小的,则当前客户端竞选Leader成功;

4. 否则,在前面的一个节点上注册watch 监听,一旦前面的节点被删除,则它得到通知,返回step3(但是,不能认为自己成为Leader节点,因为可能前面的节点只是宕机了)

5. Leader节点可以通过自行删除自己创建的节点放弃Leader;

 二、Leader Election的Curator

LeaderLatch:

  • 竞选为Leader后,不可以自行放弃Leader领导权;
  • 只能通过close方法放弃领导权;
  • 强力建议增加ConnectionStateListener,当连接suspended或者lost时视为丢弃领导权
  • 可通过await方法等待成功获取领导权,并可加入timeout;
  • 可通过hasLeadership方法判断是否为Leader;
  • 可通过getLeader方法获取当前Leader;
  • 可通过getParticipants方法获取当前竞选Leader的参与方;

LeaderSelector:

  • 竞选Leader成功后回调takeLeadership方法;
  • 可在takeLeadership方法中实现业务逻辑;
  • 一旦takeLeadership方法返回,即视为放弃领导权;
  • 可通过autoRequeue方法循环获取领导权;
  • 可通过hasLeadership方法判断是否为Leader;
  • 可通过getLeader方法方法获取当前Leader;
  • 可通过getParticipants方法获取当前竞选Leader的参与方;

三、Kafka “各自为政” Leader Eclection

  • "各自为政" Leader Election

每个Partition的多个Replica 同时竞争Leader;

  • 优点:

实现简单;

  • 缺点:

Herd Effect;羊群效应

Zookepper负载过量;

Latency(延时)较大;

 四、Kafka基于 Controller 的 Leader Election 

  • 基于Controller的Leader Election

整个集群汇中选举出一个Broker作为Controller;

Controller为所有的Topic的所有的Partition指定Leader以及Follower;

  • 优点:

极大缓解了Herd Effect问题;

减轻了Zookepper负载;

Controller 与Leader以及Follower间通过RPC通信,高效且实时;

  • 缺点:

引入Controller增加了复杂度;

需要考虑Controller的Failover;

原文地址:https://www.cnblogs.com/wangleBlogs/p/9728985.html