记一次kafka消费者不消费,消费组被踢出问题

在这里插入图片描述

描述

  • 环境:出现12台集群一个kafka节点,消费组一个java-data,消费者6个
  • 问题:运行几个小时后,开始逐步出现消费者被coordinator提出消费组,但是程序进程未退出,正常运行中。
怀疑问题
  1. 网络问题,不生产数据,一直挂起来,观察是否会被踢掉
  2. 消费阻塞
  3. 单机性能和吞吐量
  4. 分析源码,修改源码打印日志,降低到一台消费者
1. 排查日志出现
consumer poll timeout has expired. This means the time between subsequent
calls to poll() as longer than the configured max.poll.interval.ms,
which typically implies that the poll loop is spending too much time processing messages.
You can address this either by increasing max.poll.interval.ms or by reducing the maximum size of batches returned in poll() with max.poll.records.
  • 原因是因为配置 max.poll.interval.ms太大(配置的是2000),并且同步遍历消费,导致poll后处理时间过长导致poll的timeout。
  • 解决方案:把poll出来的数据异步消费-异步线程队列去消费,减少poll同步线程消费处理时间,最后没有再出现这个问题
  • 结果:本来以为已经解决问题了,结果跑了几个小时,可能多一两个小时又出现消费者被提出消费组
2.提交offset和poll同步阻塞排查
  • 怀疑是因为自动提交offset导致的.
  • 解决方案:故修改为手动提交:异步。
 consumer.commitAsync();
  • 结果:还是没解决问题最后提交offset改成了异步+同步(更新)
 try {
            long time = System.currentTimeMillis();
            websocketTask.offer(records);
            log.debug("alarmListen kafka consumer size:{} expire:{}", records.size(), System.currentTimeMillis() - time);
            // 异步提交offset,如果报错再执行异步
            consumer.commitAsync();
        } catch (Exception e) {
            log.error("alarmListen commitSync error:{},will run commitSync", e.getMessage());
            e.printStackTrace();
            try {
                // 同步提交offset
                consumer.commitSync();
            } catch (Exception exception) {
                log.error("alarmListen acknowledge error:{},will run commitSync", exception.getMessage());
                e.printStackTrace();
            }
        }
    }
3.排查版本BUG(但是没有对齐java的kafka-clients版本和kafka服务器版本)
  • 疑似kafka版本和kafka-client版本BUG

  • 解决方案:springboot版本,spring-kafka版本和kafka-client版本兼容一致,内部同步了spring-kafka和kafka-clients的版本,并且升级kafka版本为2.12-2.5.0和2.12-2.4.0。(没有同kafka服务器版本同步;比如:kafka-clients修改为2.6.0,但是kafka服务器的版本是2.12-2.5.0/2.12-2.4.0)
    在这里插入图片描述

  • 结果:没有解决问题,还是会被踢出消费组

4.排查日志发现java代码处理业务停止后 批量消费还在消费写入处理线程池队列
  • 查看已经被踢出的kafka消费组进程,发现已经占用系统20G内存,怀疑是否是处理线程出现异常退出后,没有消费,然后consumer一直再poll数据进入处理队列,最后内存太高入队失败导致最后session timeout,停止发送心跳导致被踢出消费组
  • 解决方案:排查处理业务代码,加入捕获抛出异常。
  • 结果:还是出现同样的结果,被踢出消费组,不消费
5.网络上查询到一种可能,java的sdk版本和kafka文件服务器版本不一致导致的问题

-目前java的spring-kafka是2.2.14.RELEASE和kafka-clients版本2.2.2,kafka的版本是2.12-2.3.0.

  • 解决方案:修改java端的sdk版本与kafka服务器保持一致;首先把spring-kafka的版本改为2.3.11.RELEASE和kafka-clients版本改为2.3.1,springboot版本改为2.2.10.RELEASE
  • 结果:
    • 目前已经稳定运行了13个小时,没有出现异常,运行过程中暂时没有出现什么异常情况,没有出现rabalance的情况;当前运行状态:kafka生产消息1200个/s,消费组一个,消费组6个。

    • kafka 普罗米修斯监控: 在这里插入图片描述

    • 消费组情况: 在这里插入图片描述

总结

解决问题步骤优化:

  1. 分析业务逻辑,了解所有的业务逻辑方便分析是否是业务逻辑设计出现的问题
  2. 框架使用方式,是否是使用框架不当或者是框架设计的问题
  3. 画出流程图,甘特图更加形象的分析问题
  4. 罗列可能出现问题节点
  5. 最后设计出几套解决方案(测试方案),最后按着设计的方案一个个的排查,得出最终结果。
  6. 此次处理过程中的不足:
    1. 想当然的发现问题,补充基础知识和对框架的理解
    2. 每次都是想到问题就去修改后再去尝试一下,分析不足
    3. 并且没有对当前怀疑的问题作出合理的安排和后续,没有对当前解决方案后续的分析,比如这个解决方案失败了,那么是否是继续去尝试下一步,在下一步。。。毫无规划,费事费力。
    4. 出现棘手问题,集思广益,多分析。
评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值