Kafka Leader Election

关注

原创最新推荐文章于 2026-03-14 01:45:00 发布 371 阅读 AI 写同款· GEO 优化 ›

【kafka运维】Leader重新选举运维脚本我还通过一些渠道整理了一些大厂真实面试主要有：蚂蚁金服、拼多多、阿里云、百度、唯品会、携程、丰巢科技、乐信、软通动力、OPPO、银盛支付、中国平安等初，中级，高级Java面试题集合，附带超详细答案，希望能帮助到大家。还有专门针对JVM、SPringBoot、SpringCloud、数据库、Linux、缓存、消息中间件、源码等相关面试题。《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！、缓存、消息中间件、源码等相关面试题。** 阅读详情

Zookeeper的基本操作

四种节点类型
PERSIST【永久节点，会被永久化到磁盘当中，ZooKeeper重启之后这些节点还会继续存在】
PERSIST_SEQUENTIAL【顺序节点，例如：如果有一个节点，我们将它设置成该类型，那么多个客户端可以同时重建相同的节点，但是他会根据先后顺序会在后边加一个序列号，比如第一个创建的是/a/b-00001，第二个就是/a/b-00002】
EPHEMERAL【机器重启之后，这种类型的节点不会存在】
EPHEMERAL_SEQUENTIAL【与第二种类型相反，当创建了/a/b，第二个节点继续创建，就会报错，说这个节点已经存在】
可注册Watch操作
Created event：Enabled with a call to exists【创建一个节点】
Deleted event：Enabled with a call to exists, getData, and getChildren【删除一个节点】
Changed event：Enabled with a call to exists and getData【改变某个节点的值】
Child event：Enabled with a call to getChildren【有些子节点被创建或者删除】
Watch特征
客户端先得到通知再得到数据【刚开始通过event看是不存在的，后来被创建了，客户端在得到数据之前，它肯定先得到一个通知，这个节点被创建了，或者Changed event ，getData先获取到一个值，比如：1，后来这个值被改成2，再次得到2之前肯定是先得到Changed event这个事件，然后才能得到最新的值】
Watch被fire后即取消，不会再Watch后续【如果我们希望去监控节点的变化，那么我们就需要再次去注册，那么在fire之后，到创建之前，如果这段时间中数据有变化，我们的客户端是得不到任何的通知】

基于Zookeeper的Leader Election

抢注Leader节点——非公平模式

创建Leader父节点，如 /chroot，并将其设置为persist节点
各客户端通过在/chroot下创建Leader节点，如/chroot/leader，来竞争Leader。该节点应被设置为ephemeral
若某创建Leader节点成功，则该客户端成功竞选为Leader
若创建Leader节点失败，则竞选Leader失败，在/chroot/leader节点上注册exist的watch，一旦该节点被删除则获得通知
Leader可通过删除Leader节点来放弃Leader
如果Leader宕机，由于Leader节点被设置为ephemeral，Leader节点会自行删除。而其它节点由于在Leader节点上注册了watch，故可得到通知，参与下一轮竞选，从而保证总有客户端以Leader角色工作

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

创建Leader父节点，如 /chroot，并将其设置为persist节点
各客户端通过在/chroot下创建Leader节点，如/chroot/leader，来竞争Leader。该节点应被设置为ephemeral_sequential
客户端通过getChildren方法获取/chroot/下所有子节点，如果其注册的节点的id在所有子节点中最小，则当前客户
端竞选Leader成功【没有被竞选称为Leader的节点都去注册id比自己小的并且最大的那个节点，换句话说我们把所有的节点按id去排序】
否则，在前面一个节点上注册watch，一旦前者被删除，则它得到通知，返回步骤3（并不能直接认为自己成为新
Leader，因为可能前面的节点只是宕机了）
Leader节点可通过自行删除自己创建的节点以放弃Leader

Leader Election在Curator中的实现

LeaderLatch

竞选为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 Election

“各自为政”Leader Election
每个Partition的多个Replica同时竞争Leader
优点：
实现简单
缺点：
Herd Effect
Zookeeper负载过重
Latency

Kafka基于Controller的Leader Election

基于Controller的Leader Election
整个集群中选举出一个Broker作为Controller
Controller为所有Topic的所有Partition指定Leader及Follower
优点：
极大缓解Herd Effect问题
减轻Zookeeper负载
Controller与Leader及Follower间通过RPC通信，高效且实时
缺点：
引入Controller增加了复杂度
需要考虑Controller的Failover