Kafka Leader Election

Zookeeper 节点类型

节点有两个维度，一个是永久的还是临时的，另一个是否有序。组合成的四种类型如下：

1：PERSISTENT                                //  持久化节点

2：PERSISTENT_SEQUENTIAL       //  持久化排序节点

3：EPHEMERAL                                 //  临时节点

4：EPHEMERAL_SEQUENTIAL        //  临时排序节点

永久节点：节点创建后会被持久化，只有主动调用delete方法的时候才可以删除节点。

临时节点：节点创建后在创建者超时连接或失去连接的时候，节点会被删除。临时节点下不能存在字节点。

排序节点：创建的节点名称后自动添加序号，如节点名称为"node-"，自动添加为"node-1"，顺序添加为"node-2"

 

 

可注册Watch操作

https://blog.youkuaiyun.com/qianshangding0708/article/details/50084155

 

 

 

通过Zookeeper实现的Leader Election

实现方案1_1类似kafka的实现

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

实现方案2_先到先得，后者监视前者

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

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

ephemeral_sequential

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

端竞选Leader成功

4. 否则，在前面一个节点上注册watch，一旦前者被删除，则它得到通知，返回step 3（并不能直接认为自己成为新

Leader，因为可能前面的节点只是宕机了）

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

 

Kafka 各自为政

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

缺点

•   Herd Effect
•   Zookeeper负载过重
•   Latency较大

 

Kafka基于Controller的Leader Election

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

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

优点

•  极大缓解Herd Effect问题
•  减轻Zookeeper负载
•  Controller与Leader及Follower间通过RPC通信，高效且实时

 

 

:源码

1.首先启动controller模块

方法监控Zookeeper节点,如果有数据变化,就会立马去选举

 

 

为什么要判断Leader是否是自己,是为了提高代码复用性,,别的地方也会用到该方法

 

 

2.初始化配置

 

 

 

以上是kafka初始化的代码,,,

 

 

当有Broker掉线,走的流程如下

会判断当前是否是leader,如果是,会把之前的状态清空,然后调用上面的elect方法

申请leader

 

具体实现

创建一个临时节点,如果异常了就说明抢注失败

 

 

初始化上下文,获取所有topic,在每个position上注册watch,只要有一个挂了,就会接到通知

 

上个controller可能会是哪个topic的leader,去告诉那些follow谁是新leader

 

 

 

然后程序就走完了