Leader Election

Leader Election

Zookeeper的基本操作

Zookeeper虽然是分布式系统，但它并不是为文件存储而设计的，Zookeeper里存储的一般是配置信息和源信息。实际上，Zookeeper在每个节点上存储大小都在1M一下（通常是远小于1M）

 

 

基于Zookeeper的Leader Election

抢注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角色工作

 

先到先得，后则监视前者——公平模式

1.创建Leader父节点，如/chroot。并将其设置为persist节点

2.各客户端通过在/chroot下创建Leader节点，如/chroot/leader，来竞争Leader。该节点应被设置为ephemeral_sequential

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

4.否则，在前面一个节点上注册watch，一旦前者被删除，则它得到通知，返回step3

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

 

Leader Election在Curator中实现（Curator提供2种实现）

 

 

Kafka基于Controller的Leader Election

基于Controller的Leader Election

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

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

优点

》极大缓解Herd Effect问题

》减轻Zookeeper负载

》Controller与Leader及Follower间通过RPC通信，高效且实时

缺点

》引入Controller增加了复杂度

》需要考虑Controller的Failover

注：Kafka 0.8.2之前的版本Kafka的Leader Election是由每个Patition的多个Replica同时竞争Leader。

 

接下来我们讲讲Kafka Controller，下面是Kafka的一部分源码，主要是讲Controller

  //每个server启动起来之前都要先启动kafkaController

我们进去看看

//这部分功能是监控eclectionPath，也就是Controller的Path，观察是否有数据变化

//如果有数据变化，就进入elect函数，立马做一次选举

 

我们看怎么选举的

//不管当前有没有Controller,先获取leader信息，再去判断Controller是否是leader

 

 

Controller Failover

Controller挂了，如果Controller是leader，那么新的Controller会告诉所有的和leader有关的follower新的leader，通过RPC的方式。

转载于:https://www.cnblogs.com/WardSea/p/7420302.html