Preferred Replica Election：为什么要把 Leader 放回首选副本

验证：broker复活了，但leader真实没有自动切回来

命令 · shell $ kill -9 <broker1的pid> $ sleep 8 # 真实等故障转移完成 $ kafka-server-start.sh node1/server.properties & # 真实重启broker1 $ sleep 10 # 真实等它追上ISR $ kafka-topics.sh --describe --topic leader-demo

真实实测 · 本机执行输出

Partition 0  Leader: 2  Replicas: 1,2,3  Isr: 1,2,3   ← broker1已回到Isr，但leader还是2
Partition 3  Leader: 3  Replicas: 1,3,2  Isr: 1,2,3   ← 同样，leader还是3

Replicas列表里排在第一位的1真实早就回到了ISR，具备了当leader的资格，但真实的leader依然是故障转移时接手的broker——Kafka不会因为原来的首选副本活过来了，就自动把leader还给它，这真实需要一次显式的操作。

验证：一条命令，真实修正的不只是这两个分区

命令 · shell $ kafka-leader-election.sh --bootstrap-server localhost:19092 \ --election-type preferred --all-topic-partitions

真实实测 · 本机执行输出

Successfully completed leader election (PREFERRED) for partitions
  post-kill-new-topic-0, leader-demo-0, leader-demo-3, tx-demo-0,
  after-join-topic-1, semantics-demo-0, after-join-topic-0, order-demo-1

真实一次性修正了8个分区，横跨6个不同的topic——这些真实都是本系列前面各篇实验里，因为反复kill broker做故障演练而真实积累下来的leader不均衡。--all-topic-partitions真实的意思是扫描集群里的每一个分区，只要它当前的leader不是Replicas列表里排第一的那个，就真实对它做一次preferred leader election。

结论

Kafka其实真实有一个自动做这件事的机制——auto.leader.rebalance.enable默认就是true，Controller真实每隔leader.imbalance.check.interval.seconds(默认300秒)会自己检查一遍并触发同样的操作。本文演示的手动命令，真实价值在于不用等这最长5分钟的周期——刚做完一次故障恢复、马上要做压测或者上线变更之前，运维通常真实希望立刻把leader分布拉平，而不是干等自动机制生效。长期让leader"想留在哪就留在哪"代价也是真实的：故障转移接手的那个broker，会真实持续承担原本不该属于它的那部分读写负载，其余broker反而闲着，跟本系列前面《Partition Leader 是怎么选出来的》里提到的"round-robin让负载均匀"这个初衷背道而驰。

分步演示：preferred election真实修正了什么

每一步都是本文上面真实执行kafka-leader-election.sh前后跑出来的原始结果。

一条命令拉平了整个集群积累的leader不均衡

这一步新验证的状态

参考与说明

数据来自本机3节点Kafka 4.3.1集群，累积了本系列多篇实验反复kill/重启broker留下的真实leader分布状态。
和《Partition Leader 是怎么选出来的》一起看：那篇讲初始分配和故障转移怎么产生leader，这篇讲故障恢复之后怎么把leader真实放回原位。
没有验证：auto.leader.rebalance.enable真实的自动触发时机(需要等满5分钟检查周期，本文没有实际等待验证)。

下一篇 · KAFKA 内部原理 51

Replica Fetcher：Follower 如何拉取 Leader 数据