Leader 选举

定义与作用

Leader 选举是当 Partition 的 Leader 副本故障时，Controller 从 ISR 中选择一个新 Leader 的过程。选举的正确性直接影响数据一致性和服务可用性。Kafka 的 Leader 选举策略简单且确定，避免了复杂的一致性协议。

核心原理

选举流程

选举策略

Preferred Leader

每个 Partition 有一个 Preferred Leader——即 Replicas 列表的第一个副本。Kafka 倾向于让 Preferred Leader 成为实际的 Leader，以实现初始的均匀负载分布。

# Topic: demo, Partition: 0
# Replicas: [1, 2, 3]  ← Preferred Leader = Broker 1

# Broker 1 宕机 → Broker 2 成为 Leader
# Replicas: [1, 2, 3]  Leader: 2  ← 不是 Preferred

# Broker 1 恢复 + auto.leader.rebalance.enable=true
# → Prefered Leader 选举 → Broker 1 重新成为 Leader

完整示例

示例一：手动触发 Preferred Leader 选举

场景：Broker 故障恢复后，手动让 Preferred Leader 重新接任。

操作前：

bin/kafka-topics.sh --describe --topic demo --bootstrap-server localhost:9092
# Partition: 0  Leader: 2  Replicas: 1,2,3  Isr: 1,2,3
# → Preferred Leader = Broker 1，实际 Leader = Broker 2

操作：

# 对所有 Topic 触发 Preferred Leader 选举
bin/kafka-leader-election.sh --bootstrap-server localhost:9092 \
  --election-type preferred --all-topic-partitions

操作后：

bin/kafka-topics.sh --describe --topic demo --bootstrap-server localhost:9092
# Partition: 0  Leader: 1  Replicas: 1,2,3  Isr: 1,2,3
# → Preferred Leader 恢复

示例二：Unclean Election 数据丢失实验

场景：3 副本，关闭 2 个 ISR 副本后验证 Unclean Election 的影响。

操作前：Topic test-uce，3 分区，3 副本。

bin/kafka-topics.sh --describe --topic test-uce --bootstrap-server localhost:9092
# Partition: 0  Leader: 1  Replicas: 1,2,3  Isr: 1,2,3

操作步骤：

# 1. 写入 100 条消息（Offset 0-99）
for i in $(seq 1 100); do
  echo "message-$i" | bin/kafka-console-producer.sh \
    --topic test-uce --bootstrap-server localhost:9092
done

# 2. 关闭 Broker 1（Leader 和唯一完全同步的副本）
kill $(jps | grep "server1" | awk '{print $1}')

# 3. 关闭 Broker 2（ISR 副本）
kill $(jps | grep "server2" | awk '{print $1}')

# 4. 只剩 Broker 3（假设是 ISR 但未完全同步）
# 此时 ISR=[3]，Leader=3
bin/kafka-topics.sh --describe --topic test-uce --bootstrap-server localhost:9093
# Partition: 0  Leader: 3  Replicas: 1,2,3  Isr: 3

如果 Broker 3 只同步到 Offset 80，则 Offset 81-99 丢失。

操作前后对比：

时间点	Leader	ISR	数据范围
初始	1	[1,2,3]	Offset 0-99
Broker 1+2 故障后	3	[3]	Offset 0-80（如 B3 落后）

易错场景

易错 1：误以为 Kafka 支持 Raft 式的多数派选举

场景：Kafka 3 副本，2 台宕机，期望剩余 1 台能选出 Leader。

事实：Kafka 不是 Raft 共识副本（副本间不投票）。只有 Controller 决定谁当 Leader——且只在 ISR 中选。如果 ISR 全宕机，则分区不可用（除非开启 unclean.leader.election）。

易错 2：故障恢复后未触发 Preferred Leader 选举

场景：Broker 故障恢复后，长期处于 Follower 角色，导致 Leader 分布不均。

解决：

# Broker 配置（自动 Preferred 选举）
auto.leader.rebalance.enable=true
leader.imbalance.check.interval.seconds=300
leader.imbalance.per.broker.percentage=10

面试高频考点

Q：Kafka 为什么不采用 Paxos/Raft 来选 Leader，而是 Controller 指派？

A：

Kafka 的选举不涉及数据一致性——数据已经在磁盘上。Leader 选举只是"从已有数据的副本中选一个"，不需要共识算法来确定"谁有最新数据"。
ISR 机制已经确保了候选者都有（近似）完整的数据——Leader 只在 ISR 中选，而 ISR 中的副本与 Leader 数据相差在可接受范围内。
由 Controller 集中指派比分布式选举快得多：一次 RPC 即可完成。
Raft/Paxos 的选举需要多轮投票，延迟高，不适合 Kafka 可能有数千分区同时需要换 Leader 的场景。