Kafka Broker触发分区Leader选举的场景有哪些？如何复现NOT_LEADER_FOR_PARTITION异常？

一、Leader选举的其他触发场景 #

除Broker节点故障下线外，以下场景也会触发Kafka分区的Leader选举：

• Broker优雅关闭：执行kafka-server-stop.sh等命令正常关闭Broker时，该节点上的所有分区会主动触发Leader选举，将Leader转移到ISR集合中的其他副本。
• 手动触发Leader重平衡：通过kafka-leader-election.sh工具（或Kafka Admin API）手动发起指定分区或全集群的Leader选举操作。
• 分区副本调整：给分区添加新副本、移除现有副本（尤其是移除当前Leader副本）时，会触发Leader重新选举以保证分区可用性。
• Controller节点切换：当集群的Controller Broker故障，新Controller当选后，会重新校验集群内所有分区的Leader状态，必要时触发选举。
• ISR集合变更：当Leader的同步副本集合（ISR）发生变化（如副本长时间同步失败被踢出ISR），结合集群配置（如unclean.leader.election.enable开启）可能触发选举；另外开启auto.leader.rebalance.enable=true时，Kafka会定期检查Leader分布均衡性，自动触发选举调整。
• 自动Leader重平衡：开启auto.leader.rebalance.enable配置后，Kafka会周期性评估集群Leader分布，若存在不均衡情况，会自动触发Leader选举以优化集群负载。

二、NOT_LEADER_FOR_PARTITION异常复现方案 #

你通过停止虚拟机的方式未复现成功，大概率是因为Broker突然下线后无法响应请求，生产者会触发连接超时而非收到明确的NOT_LEADER_FOR_PARTITION错误。可以尝试以下步骤：

1. 配置生产者客户端：修改生产者参数，设置metadata.max.age.ms=3600000（将元数据自动更新间隔设为1小时，避免生产者主动获取新元数据），同时确保bootstrap.servers指向集群地址。
2. 定位目标分区Leader：执行命令查询目标Topic的分区Leader信息：

   kafka-topics.sh --describe --topic <你的Topic名称> --bootstrap-server <Broker地址:端口>
   

   记录下目标分区的Leader对应的Broker ID。
3. 优雅关闭Leader Broker：找到该Broker所在节点，执行优雅停止命令：

   kafka-server-stop.sh
   

   此时Broker会正常处理剩余请求并告知集群自身即将下线，不会立即断开连接。
4. 立即发送消息：使用配置好的生产者向集群发送消息（由于生产者元数据未更新，会继续向旧Leader发送请求），此时旧Broker会返回NOT_LEADER_FOR_PARTITION异常，因为它已经知道自己不再是该分区的Leader。

另外，也可以通过手动触发Leader选举的方式复现：在生产者持续发送消息过程中，执行以下命令将目标分区的Leader切换到其他Broker，生产者因元数据未更新继续向旧Leader发消息时，也会触发该异常：

kafka-leader-election.sh --bootstrap-server <Broker地址:端口> --topic <你的Topic名称> --partition <分区号> --election-type PREFERRED

内容的提问来源于stack exchange，提问作者R Sriram