记Kafka消费组异常离线

现象

生产环境出现大量消费数据异常中断，时不时能出现消费数据，过一会又会存在数据批量消费一批,导致出现数据消费异常，特别是针对心跳数据，存在较大影响，导致心跳时而在线时而离线，很不稳定。

排除过程

1、查看是否存在数据高峰堆积？
通过查看对应的topic的生产消息频率以及当前产生数据的应用以及根据当前日志查看，不可能会产生数据堆积情况。

2、线上环境消费者应用是否出现重启？
通过运维查看当前服务对应的多个pod节点查看其启停时间，以及根据应用查看启动日志，并未发现出现重启日志，所以排除该情况

3、查看系统是否存在异常日志?
整个系统查看并未出现致命的ERR级别日志，并且在未消费的时间段内并未发现固定的异常日志。

4、查看非业务的Info级别日志？
排查整个系统，查看在出现消息不能正常消费期间，查看是否框架或者其他中间件是否存在抛出了异常信息。

• 4.1 经过查看果然发现了非业务的INFO级别日志（listenAsyncRespMsg consume has failed,will exit）,具体信息如下：
  

• 4.2 根据日志排查具体抛出的原因，定位到为Kafka框架中抛出，方法是consume中的实现抛出，方法为:
  

• 4.3 通过日志定位，发现日志信息为自身框架打印，查看kafka框架调用kafka的consume方法，其中的err并未发现有异常信息返回：
  

• 4.4 进入consume方法进行查看，此方法退出，并且无任何异常输出，满足条件的仅为ctx接收到了退出信号量，并进行了消费者退出具体如下：
  

• 4.5快速定位为何会此处的ctx退出在哪些地方进行了关闭或者超时操作，经过查看调用，定位到如下关键点：
  此处为创建消费组时，同时会针对该消费组创建对应的心跳，如果当前消费组的心跳无法正常请求访问到服务端时，此处会发生超时并且退出ctx。
  
  此处为循环当前每个topic以及topic中对应的多个分区进行以协程的方式进行监听，当分区消费存在异常的情况下，则会进行退出。
  

• 4.6 针对以上情况，进行defer的方式判断具体退出的为那种情况，经过代码以及异常情况的复现，判断当前ctx的退出为 消费组心跳超时抛出，判断当前消费组异常离开，触发了Kafka的动态重平衡机制，具体异常信息为：ErrRebalanceInProgress（27）
  -4.7 查看kafka默认消费组的超时时间以及心跳频率配置
  
  10s中判断为当前消费组离线，触发重平衡，以及心跳频率为每3s发送一次。

心跳机制为：

0.10.1.0 的心跳机制：
从该版本开始，heartbeats 与 poll 解耦，每个线程有独立的心跳维护机制。
从该版本开始新增了独立的 max.poll.interval.ms 参数。这样可以单独配置两次 poll 轮训的间隔时间，这就使得可以配置 poll 轮训间隔时间大于 heartbeats 心跳间隔，即消费者处理消息的时间可以独立配置，允许消息处理时间大于心跳时间（会话超时时间 session.timeout.ms）。
session.timeout.ms 用于心跳维护线程，max.poll.interval.ms 用于消费处理线程。该版本存在两个独立的线程。

假设 session.timeout.ms = 30000，即30秒，则消费者心跳线程必须在此超时之前向服务端发送心跳。
另一方面，如果单个消息处理需要1分钟，则可以将 max.poll.interval.ms 设置大于1分钟，以便为消费处理线程提供更多的时间来处理消息。
否则，如果 max.poll.interval.ms < 1分钟，会导致单个消息处理完、等下次 poll 的时候，因为两次 poll 超出了 max.poll.interval.ms 而导致 poll 失败（即使 session 未超时，poll 还是会失败）。

如果处理（poll）线程挂掉，服务端可以通过 max.poll.interval.ms 来检测到。
如果整个消费者（Consumer）挂掉，则只能通过 session.timeout.ms 来检测到

总结

1、判断业务是否存在执行较长的业务逻辑，如果存在则进行优化。
2、如果确实业务处理时间周期较长，则针对该配置进行更改，建议将该时间调长，将心跳发送的频率降低，判断离线的时间加长即可，建议最少以三倍进行调整。