两种 Leader 选举的差别
分区的 leader 通常是分配时确定的「首选副本」（replicas 列表里的第一个）。集群做过运维变更、broker 重启或下线后，leader 可能大量集中到少数节点上，此时用 PREFERRED 选举把 leader 迁回首选副本，恢复负载均衡。另一种 UNCLEAN 选举是最后手段：只在 ISR 中所有副本都不可用时，从非同步副本里选 leader，代价是可能丢掉尚未同步的消息。
基本信息
| PREFERRED | 把 leader 迁回 replicas 列表首位副本，用于负载均衡 |
|---|---|
| UNCLEAN | ISR 全部不可用时从非同步副本选主，可能丢数据 |
| 范围参数 | --all-topic-partitions，或 --topic 加 --partition |
| 前提条件 | controller 工作正常，目标副本在线 |
典型使用场景
- broker 重启或扩缩容后，把 leader 分布重新拉回均衡
- 单分区 leader 异常时，手动触发选举恢复可用性
- 节点下线维护前先迁走 leader，减少切换时的抖动
- 机房级故障后确认 leader 是否已按预期恢复
- 演练验证：测量选举流程耗时与恢复过程是否符合预期
首选副本选举与应急选举
首选副本选举与应急选举
# 全量首选副本选举：把 leader 迁回首选副本，用于负载均衡
kafka-leader-election.sh --bootstrap-server localhost:9092 \
--election-type PREFERRED --all-topic-partitions
# 只对单个分区操作，粒度更小、影响面可控
kafka-leader-election.sh --bootstrap-server localhost:9092 \
--election-type PREFERRED --topic orders --partition 0
# UNCLEAN 仅在所有 ISR 副本都不可用、必须恢复写入时使用
kafka-leader-election.sh --bootstrap-server localhost:9092 \
--election-type UNCLEAN --topic orders --partition 0两种选举对比
| 维度 | PREFERRED | UNCLEAN |
|---|---|---|
| 触发条件 | 副本在线，仅迁移 leader 角色 | ISR 全部不可用 |
| 数据影响 | 不丢数据 | 可能丢失未同步消息 |
| 典型场景 | 负载均衡与维护窗口 | 单分区不可写的紧急恢复 |
| 主要风险 | 批量执行会加重 controller 负担 | 一致性受损，需要人工核对 |
UNCLEAN 选举是数据安全上的最后手段：只有在明确接受该分区丢失尚未同步消息的前提下才使用，事后必须核对数据缺口并补数。
首选副本选举是轻量操作，但不等于负载会自动均衡：每次运维变更后分布都可能再次失衡，长期均衡仍然依赖副本分布规划与定期巡检。