node-rdkafka问题：Consumer运行一段时间后自动断开连接

问题现象 #

应用启动时node-rdkafka的Consumer连接状态正常，可通过日志确认其处于正常消费消息的状态。但运行一段时间后，Consumer会停止消费消息，同时在消费者控制台中看不到与该应用地址关联的broker连接。

核心排查方向 #

• 检查消费超时相关参数配置是否合理
  重点核对max.poll.interval.ms和session.timeout.ms两个参数：
  前者控制消费者两次拉取消息的最大间隔，如果单条消息处理耗时超过max.poll.interval.ms阈值，或者消费逻辑阻塞导致长时间未发起poll请求，Kafka协调器会判定消费者状态异常，将其踢出消费者组并断开连接。如果业务存在长耗时消费逻辑，需要将该参数调整为大于业务最大处理耗时的数值，同步调大session.timeout.ms心跳超时阈值。
• 检查消费逻辑异常捕获完备性
  消费回调中如果抛出未捕获的异常，会直接中断消费流程，但底层librdkafka连接不会主动上报断连错误，表现为消费者进程存活但不再拉取消息。需要在消费回调外层添加try/catch逻辑捕获所有异常，打印错误日志后继续消费流程，避免单次异常终止消费链路。
• 检查网络空闲连接保活配置
  部分版本的node-rdkafka依赖的底层librdkafka默认未开启TCP keepalive，长时间无消息传输时，网络中间链路的防火墙、负载均衡等设备会主动切断空闲连接，导致消费者和broker的连接中断但客户端未感知。建议显式开启socket.keepalive.enable = true配置，同时调小socket.connection.setup.timeout.ms、reconnect.backoff.max.ms参数，让客户端可以快速感知断连并自动触发重连。
• 检查Node.js事件循环阻塞问题
  Node.js为单线程事件循环模型，如果消费逻辑中存在CPU密集型运算、同步阻塞IO操作会占用事件循环资源，导致消费者的心跳请求无法正常触发，broker长时间收不到心跳会主动断开连接。可通过性能工具排查事件循环延迟问题，CPU密集型任务建议移入worker线程处理，避免阻塞主进程逻辑。

快速定位方法 #

复现问题时可临时开启debug: 'cgrp,broker,topic'的调试配置，通过librdkafka输出的底层日志可以直接定位断连触发的具体原因，是协调器主动踢除消费者还是网络层异常导致的断连。

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