Kafka首个Broker宕机后消费者无法消费问题求助

Hey there, let's dig into what's going on with your Kafka cluster and how to get your consumers back to working properly when a broker goes down.

你的场景回顾 #

• 你使用的是kafka_2.12-1.0.0.tgz（一个相对较早的Kafka版本）搭建了3节点Broker集群，仅修改了每个实例的broker.id和listeners=PLAINTEXT://:9092（推测每个Broker分别用了9092、9093、9094端口）
• 创建topic的命令：

  ./kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 13 --topic demo
  

• 启动生产者和消费者的命令：

  # 生产者
  ./kafka-console-producer.sh --topic demo --broker-list localhost:9094,localhost:9093,localhost:9092
  # 消费者（属于test消费组）
  ./kafka-console-consumer.sh --group test --bootstrap-server localhost:9094,localhost:9093,localhost:9092 --topic demo
  

• 问题现象：关闭第一个启动的Broker后，生产者能正常发消息，但消费者无法接收；重启该Broker后，消费者立即收到积压的消息。

问题根源分析 #

从你的消费者日志里的The coordinator is not available和Connection to node 2147483646 could not be established这些关键错误可以看出：

• 你关闭的那个Broker，恰好是test消费组的消费者协调器（Consumer Coordinator）。Kafka的消费组依赖协调器来管理成员、分配分区、处理offset提交等核心操作。
• 在Kafka 1.0.0这个旧版本中，当协调器宕机后，消费者重新发现新协调器的机制不够完善：
  • 消费者需要等待元数据刷新、新协调器选举完成，但默认的配置参数可能导致这个过程太慢，甚至卡在等待状态。
  • 日志里的2147483646是一个临时节点ID，代表消费者还未定位到新的协调器Broker。

重启Broker后出现的This is not the correct coordinator错误，是因为旧协调器恢复后，集群已经选举了新的协调器，消费者需要重新同步最新的协调器信息，之后就能恢复正常消费。

解决方案 #

1. 优先升级Kafka版本 #

Kafka 1.0.0是2017年发布的版本，后续的2.0+版本对消费者协调器的故障转移做了大量优化，能自动、快速地完成新协调器的发现和切换，从根源上解决这类问题。

2. 调整消费者配置（暂时无法升级时） #

修改消费者的配置参数（可以通过命令行参数或者消费者配置文件添加），加快协调器的重新发现速度：

• --session.timeout.ms 10000：缩短会话超时时间，让消费者更快检测到协调器不可用，触发重新选举
• --reconnect.backoff.ms 500和--reconnect.backoff.max.ms 2000：减少重连等待时间，让消费者更快尝试连接其他Broker
• --metadata.max.age.ms 60000：缩短元数据刷新间隔，让消费者更快获取集群最新的协调器信息

修改后的消费者启动命令示例：

./kafka-console-consumer.sh --group test --bootstrap-server localhost:9094,localhost:9093,localhost:9092 --topic demo --session.timeout.ms 10000 --reconnect.backoff.ms 500 --reconnect.backoff.max.ms 2000 --metadata.max.age.ms 60000

3. 完善Broker配置 #

你当前只修改了broker.id和listeners，建议补充配置每个Broker的advertised.listeners：
每个Broker的server.properties中添加对应端口的配置，比如：

# Broker 1的配置
advertised.listeners=PLAINTEXT://localhost:9092
# Broker 2的配置
advertised.listeners=PLAINTEXT://localhost:9093
# Broker 3的配置
advertised.listeners=PLAINTEXT://localhost:9094

这个配置是客户端用来获取Broker实际地址的关键，如果缺失，可能导致消费者无法正确定位到新的协调器。

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