线上排查导致Kafka客户端频繁断开的原因竟然是一行count++代码

就在上周公司某个系统的Kafka多个环境频繁宕机，让我给你慢慢说来！

---

是这样的，上周的某一天，接到同事的报案：数据库没有回显，看一下Kafka数据目前处理不正常。接到报案后我就开始排查。

排查的开始我以为是心跳检测的时间不足以完成业务处理呢，于是我修改了Kafka的这两个配置项session.timeout.ms（心跳检测时间）、max.poll.records（一次拉取消息条数），根据我的估算修改参数后，发现并没有任何效果。

Kafka宕机后，重新启动Kafka所在的服务器，随后Kafka就开始分配消费者组等就可以进行消费了，但是消费消息有些异常。经过多次测试，发现了一个Kafka消费异常的规律

消费异常规律：每次重启Kafka客户端之后，在宕机的时间段内堆积的消息就会被Kafka消费掉，直到生产者生产一条消息送到消费端开始消费，期间并没有返回任何结果，随后Kafka客户端再次离线。如果再重启Kakfa客户端，将循环往复这个过程。

Kafka监控

根据系统打印的日志，重新启动Kafka客户端之后，生产者生产一条消息时，查看监控确定Kafka将消息送往了消费端。查看消费端日