Go语言confluent-kafka-go客户端生产消费超时断开问题咨询

问题1 报错原因 #

报错的核心原因是客户端和Confluent云Kafka集群之间的TCP长连接被中间网络设备主动断开，客户端未及时感知导致请求超时。
结合你提供的环境信息，大概率是AWS EKS集群的NAT网关默认空闲连接超时机制触发：AWS NAT网关默认会断开闲置超过350秒的TCP连接，而你当前的Kafka客户端配置未开启TCP保活探测，或保活探测间隔超过350秒，连接被掐断后客户端仍判定连接正常，发送生产请求后等待响应超时，就会抛出REQTMOUT、Broker transport failure类错误。
另外你使用的confluent-kafka-go v1.7.0版本对应的底层librdkafka版本较老，部分版本存在断连后自动重连不及时的已知问题，也会放大该报错的影响。

问题2 Producer使用方案 #

• 原生librdkafka实现的Producer没有内置的超时/过期机制，应用生命周期内复用单例Producer是官方推荐的最佳实践，完全不需要调整为每次发消息新建实例：频繁创建Producer不仅会导致生产延迟飙升，还会快速占满Kafka集群的可用连接数，引发更严重的可用性问题。
• 你当前场景下不需要调整单例架构，只需要补充配置让Producer支持自动断连重连、合理的重试机制即可解决现有问题。

问题3 推荐配置优化及最佳实践 #

通用配置（生产者、消费者都需要添加） #

• 开启TCP保活，调整保活间隔小于AWS NAT网关的350秒超时：

socket.keepalive.enable: true
socket.keepalive.idle: 120 // 连接空闲120秒就开始发送保活包
socket.keepalive.interval: 30 // 每30秒发一次保活包
socket.keepalive.count: 3 // 3次无响应就判定连接失效

• 增加broker地址重试解析配置，避免DNS更新后客户端无法识别新的broker地址：

socket.nagle.disable: true
broker.address.ttl: 300000 // 每5分钟重新解析一次broker域名

生产者专属配置 #

• 增加请求超时、重试相关配置，避免偶发网络波动导致生产失败：

acks: "all" // 按需调整，数据可靠性要求高建议设置为all
retries: 3 // 可重试错误的重试次数
retry.backoff.ms: 100 // 重试间隔
message.timeout.ms: 30000 // 单条消息最大发送超时时间，超过则抛错给上层业务
enable.idempotence: true // 开启幂等，避免重试导致重复消息

• 你当前配置的BatchSize为100000（100KB）、LingerMs为10ms，若生产吞吐量不大可保持不变，吞吐量较高的话可以酌情调整LingerMs到20-50ms提升批量发送效率。

消费者专属配置 #

• 增加会话超时、心跳间隔配置，避免消费者被组协调器意外踢出消费组：

session.timeout.ms: 30000
heartbeat.interval.ms: 3000
auto.offset.reset: "earliest" // 按需调整，避免无提交偏移量时消费不到数据
enable.auto.commit: true // 如果是手动提交偏移量可关闭，根据你的业务逻辑调整

其他最佳实践 #

• 尽量将confluent-kafka-go升级到最新的v1.x稳定版，修复底层librdkafka的已知断连、重连bug。
• 生产、消费逻辑都要添加错误处理，捕获到Local: Broker transport failure类错误时不要直接退出进程，librdkafka会自动重连，只需要记录日志、重试对应操作即可。
• EKS集群的安全组、网络ACL要放开Kafka集群9092端口的出方向访问，不要额外限制连接时长。

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