咱们先从Kafka 2.2.0版本的__consumer_offsets主题副本分配逻辑说起——这是你问题的核心突破口。

因为你的集群是3个broker（ID0/1/2），副本因子设为2，且__consumer_offsets自动创建了100个分区，Kafka会按轮询策略给这些分区分配副本。简单说，分区的副本分布会是这样的循环模式：

• 分区0：副本组是broker0 + broker1
• 分区1：副本组是broker1 + broker2
• 分区2：副本组是broker2 + broker0
• 分区3：副本组是broker0 + broker1
• ...以此类推

所以那些编号满足分区号 % 3 == 0的分区（比如0、3、6、9），它们的副本里根本没有broker2！这就解释了为什么broker2存活却无法成为这些分区的Leader——它连副本成员都不是，自然没有选举资格。而你提到的分区2、5、8，它们的副本组包含broker2，所以broker0下线后，broker2能正常补位成Leader。

你可以针对性查看以下日志，验证上述推论并排除其他隐性问题：

• Controller节点日志（当前Controller应该是broker1或2）：搜索关键词Partition [__consumer_offsets, X]（X替换成0、3、6、9这类出问题的分区），看看有没有No alive brokers in the ISR for partition或Leader election failed for partition的报错。如果有，说明这些分区的存活副本（也就是broker1）可能处于异常状态。
• Broker1的日志：搜索ReplicaFetcherThread或ISR相关内容，确认broker1是否真的是这些分区的同步副本——比如有没有因为磁盘IO过高、网络卡顿导致它被踢出ISR？如果broker1不在ISR里，那这些分区就只剩下线的broker0，自然选不出Leader。
• 所有Broker的ZK连接日志：搜索ZooKeeperClient，看看在broker0下线后，剩余broker和ZK集群的连接是否稳定。哪怕ZK集群整体正常，个别broker的ZK会话超时或断开，也会影响Controller的Leader选举决策。

还有几个隐性场景可能导致这个现象，你可以逐一排查：

• Broker1的隐性资源耗尽：虽然你没找到双重故障的直接日志，但broker1可能出现CPU/内存打满、磁盘空间不足的情况，导致它无法响应Controller的选举请求，或者无法同步分区数据被踢出ISR。这种情况下，分区的ISR里只剩下线的broker0，自然无法选举Leader。
• ZK集群的短暂同步延迟：当broker0对应的ZK节点下线后，ZK集群需要重新选举Leader，这个过程中可能有几秒的同步窗口，导致Kafka Controller无法及时获取最新的broker存活状态，从而延迟或失败触发Leader选举。
• __consumer_offsets的min.insync.replicas配置异常：检查这个主题的min.insync.replicas值，如果被设为2，那么当只有1个存活副本时，Kafka为了保证数据一致性，会拒绝选举Leader，直接让分区Leader变为-1。你可以用命令kafka-topics.sh --describe --topic __consumer_offsets --bootstrap-server <你的broker地址>:9092查看这个配置。

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