Kafka Leader 选举和故障恢复是怎么做的？
面试怎么回答
Kafka 每个分区由 Leader 提供主要读写，Follower 复制日志。Leader 所在 Broker 故障后，控制器识别受影响分区，优先从满足安全条件的副本中选择新 Leader，更新 Leader epoch 和元数据，再通知 Broker 与客户端重新路由。如果没有安全候选，就要在等待恢复和允许落后副本接管之间权衡。生产上我会提前监控 ISR 收缩、未充分复制分区和 Leader 分布，而不是等选举发生后才处理。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
一个 Broker 宕机后，Kafka 不是简单从所有存活副本里随便挑一个 Leader。
选谁，决定了分区能否快速恢复，也决定了有没有可能丢失已经写入但尚未同步的数据。
Leader 选举的核心，是由控制器选择满足条件的副本接管分区，并通过新的 Leader epoch 和元数据传播恢复读写。
先分清 Leader、Follower 和控制器
每个分区有一个 Leader，客户端的读写请求通常都由 Leader 处理，Follower 持续复制日志。
集群控制器负责感知 Broker 状态并处理受影响分区的 Leader 变化。KRaft 模式下，控制器职责由控制器仲裁集群承担，不要再机械背诵“某个 ZooKeeper Controller 节点”。
安全候选比“活着”更重要
经典理解里，ISR 中的副本被认为与 Leader 保持足够同步，Leader 失败时优先从合格副本中选择新的 Leader。
如果没有满足安全条件的候选，系统就面临一致性和可用性的取舍：等待可靠副本恢复会暂时不可用；允许落后副本接管则可能丢失最新消息。较新的 Kafka KRaft 版本还可能使用 Eligible Leader Replicas，具体行为要结合版本与配置说明。
选举完成后还要传播元数据
控制器确认新的 Leader 后，会更新分区元数据并通知相关 Broker。Leader epoch 用于区分领导任期，防止旧 Leader 恢复后继续以过期身份提供服务。
客户端遇到 NOT_LEADER_OR_FOLLOWER 等错误后会刷新元数据，把请求路由到新 Leader。因此故障恢复时间不仅包含选举，还包含通知和客户端重试。
恢复后要处理领导分布不均
Broker 重启后，原来的 Leader 不一定马上切回，可能造成领导分区集中在少数节点。Kafka 有 preferred replica 的概念，可以自动或人工恢复较均衡的 Leader 分布。
排障时我会关注 OfflinePartitions、UnderReplicatedPartitions、ISR shrink、Leader election 速率以及各 Broker 的 Leader 数量，而不是只看进程是否存活。
一个典型场景
某个 Broker 故障后，一批分区短暂不可用。表面看还有其他副本存活，继续检查却发现它们已经长时间落后并退出安全候选集合。
这时强行允许落后副本接管可以更快恢复，但会引入数据丢失风险。真正的根因不是“选举太慢”，而是复制链路早已异常，只是一直没有处理 ISR 收缩告警。
Leader 选举是最后一道恢复动作，副本健康才是前置条件。