Kafka Streams节点故障后持续输出‘Discovered transaction coordinator’日志问题

你的问题核心是Kafka Streams在EXACTLY_ONCE_V2（EOS V2）模式下，依赖的事务协调器高可用配置不足，导致单个节点宕机后，事务状态日志无法正常读写，Streams线程的事务生产者无法完成初始化，进而陷入停滞。以下是具体的排查和配置调整方案：

一、集群层面关键配置检查 #

• 事务状态日志高可用配置：
  EOS V2依赖__transaction_state内部主题存储事务元数据，必须确保该主题的副本数和最小同步副本数匹配集群规模：

  # 3节点集群设置为3，和节点数一致
  transaction.state.log.replication.factor=3
  # 最小同步副本数设为2，确保单个节点宕机后仍有足够副本提供服务
  transaction.state.log.min.isr=2
  

• 偏移量主题高可用配置：
  偏移量提交是EOS事务的一部分，同样需要保证__consumer_offsets主题的高可用：

  offsets.topic.replication.factor=3
  offsets.topic.min.isr=2
  

二、Kafka Streams客户端配置调整 #

• 延长事务超时时间：
  节点宕机后集群重新选举协调器需要时间，默认的30秒超时可能不够，建议调整为60秒：

  props.put(StreamsConfig.TRANSACTION_TIMEOUT_CONFIG, 60000);
  

• 优化生产者重试策略：
  增加重试次数和间隔，给集群足够的时间完成协调器切换：

  props.put(ProducerConfig.RETRIES_CONFIG, 10);
  props.put(ProducerConfig.RETRY_BACKOFF_MS_CONFIG, 1000);
  

• 确认Streams核心配置：
  确保processing.guarantee严格设置为exactly_once_v2，同时避免线程数过多导致资源竞争：

  props.put(StreamsConfig.PROCESSING_GUARANTEE_CONFIG, StreamsConfig.EXACTLY_ONCE_V2);
  props.put(StreamsConfig.NUM_STREAM_THREADS_CONFIG, 2); // 根据服务器CPU核心数调整
  

三、集群运维检查项 #

• 检查内部主题ISR状态：
  节点宕机后，执行以下命令查看__transaction_state和__consumer_offsets的ISR列表，确保存在至少2个存活节点：

  kafka-topics.sh --describe --topic __transaction_state --bootstrap-server <存活Broker地址>:9092
  kafka-topics.sh --describe --topic __consumer_offsets --bootstrap-server <存活Broker地址>:9092
  

• 确认事务协调器选举结果：
  日志中显示的协调器ID为3，若关闭的节点正是该Broker，需确认集群已成功选举新的协调器——通过上述命令查看__transaction_state的leader是否切换到存活节点。
• 禁用非ISR节点选举leader：
  确保所有Broker的unclean.leader.election.enable设置为false，避免非同步副本成为leader导致事务元数据不一致。

为什么AT_LEAST_ONCE模式正常？ #

AT_LEAST_ONCE模式不依赖事务协调器，消费者直接提交偏移量，不需要完成事务初始化、提交等全流程，因此节点宕机后只需重新连接存活Broker即可恢复消费。而EOS V2模式下，每个Streams处理线程都绑定一个事务生产者，必须与协调器完成握手和事务初始化才能开始处理消息，一旦协调器不可用或选举受阻，就会出现停滞。

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