Kafka部分Broker宕机时生产者是否异常？附测试场景与配置

核心影响因素分析 #

结合你的Topic配置（副本数2、分区数3）和生产者配置，分场景讨论：

1. 剩余Broker数量≥2时的情况 #

你本地测试关闭1个Broker无异常，是因为：

• 正常情况下3个Broker会把3个分区的2个副本均匀分布（比如分区1副本在Broker1/2，分区2在Broker2/3，分区3在Broker1/3）
• 关闭1个Broker后，剩余2个Broker仍持有所有分区的至少1个副本，Kafka会快速完成leader副本选举（从存活的follower中选新leader）
• 你的生产者acks=1只需要当前分区的leader确认即可，所以选举完成后写入会恢复正常；若选举时间极短，甚至不会感知到异常

但如果关闭的Broker恰好是多个分区的leader，且你的生产者未配置重试（retries默认0，enable.idempotence=false），选举期间会出现临时的写入超时错误，不过选举完成后后续写入会恢复。

2. 仅剩余1个Broker时的情况 #

这种场景下必然会出现写入失败，原因是：

• 你的Topic每个分区有2个副本，3个分区均匀分布在3个Broker上时，每个Broker最多持有2个分区的副本（比如Broker1持有分区1、3的副本，Broker2持有分区1、2的副本，Broker3持有分区2、3的副本）
• 当只剩1个Broker时，必然存在至少1个分区的两个副本都在已宕机的Broker上（比如只剩Broker1时，分区2的副本在Broker2/3，均已宕机）
• 该分区无法选举出可用的leader，生产者写入该分区时，会持续触发请求超时，最终超过delivery.timeout.ms=120000后抛出写入失败的错误

结合你的生产者配置补充说明 #

• acks=1：写入成功依赖分区leader的确认，若某个分区无可用leader，写入必然失败
• retries=0（默认值）：没有重试机制，一旦请求超时就直接报错；若开启重试（设置retries>0），则在leader选举完成后可能自动恢复写入，但仅针对有可用副本的分区
• delivery.timeout.ms=120000：若超过这个时间仍无法完成写入，生产者会抛出异常终止写入

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