小桀
消费确认失败的问题

消费确认失败的问题

问题描述

  1. 异常如下：

org.apache.kafka.clients.consumer.CommitFailedException: Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member. This means that the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms, which typically implies that the poll loop is spending too much time message processing. 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.
	at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.sendOffsetCommitRequest(ConsumerCoordinator.java:820) ~[kafka-clients-2.3.1.jar!/:?]
	at org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.commitOffsetsSync(ConsumerCoordinator.java:692) ~[kafka-clients-2.3.1.jar!/:?]
	at org.apache.kafka.clients.consumer.KafkaConsumer.commitSync(KafkaConsumer.java:1454) ~[kafka-clients-2.3.1.jar!/:?]
	at org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.commitIfNecessary(KafkaMessageListenerContainer.java:2026) ~[spring-kafka-2.3.6.RELEASE.jar!/:2.3.6.RELEASE]
	at org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.processCommits(KafkaMessageListenerContainer.java:1849) ~[spring-kafka-2.3.6.RELEASE.jar!/:2.3.6.RELEASE]
	at org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.pollAndInvoke(KafkaMessageListenerContainer.java:981) ~[spring-kafka-2.3.6.RELEASE.jar!/:2.3.6.RELEASE]
	at org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.run(KafkaMessageListenerContainer.java:927) ~[spring-kafka-2.3.6.RELEASE.jar!/:2.3.6.RELEASE]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_242]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_242]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_242]

探索过程

  1. 直接Google查到了是因为消费者没有在Kafka指定的时间内确认消费，直接导致了该异常。我们修改了该指定时间，从默认的300秒改为了500秒，问题依旧。
  2. 我尝试使用stack查看jvm运行信息，没有结果（很多东西忘记，加之之前主要学习JProfile，总之基本功不到位）
  3. 我尝试配置log4j2让log4j2打印更详细的日志，失败了（log4j2的使用经验比较少，配置没有研究过）
  4. 其实我想拥有命令行权限，尝试使用更高级的工具，但是没有获得该权限（所以放弃了）
  5. 最后欣哥告诉我们，该问题出现过，是一个已知的问题，于是智敏直接操作了数据库中相关的数据，该问题应该可能被解决了（没有验证，参考下一点）
  6. 运维的同事也知道这是一个已知的问题，之前的解决方案为跳过Kafka中的该消息，我们采用该方案，该问题立即得到解决

问题原因

  1. 我们在消费消息的时候，会拿到某个消息中的数据，然后去查相关的记录，查到的记录有一千多条，我们会在一个循环中通过同步调用完成我们的功能，最后导致消费该消息的时间非常的长，最终抛出如上异常。
  2. 我们在该主题的消费为顺序消费，所以一旦一个消息阻塞就会导致消息积压，而且有个更恐怖的问题，如果消费者总是无法消费确认，最终会导致消费者掉线，最终导致整个job-center都不是正常的（需要再确认细节）

解决问题时的不足

  1. 无法看到Kafka中目前阻塞流程的消息是什么？
  2. 对jvm提供的命令行工具使用不熟练，之前有意识到命令行工具才是服务端的利器，但是一直没有下定决心去学习
  3. 对Kafka不够了解，基础概念忘了很多（之前学习大数据时有系统学习过，不过都差不多忘记了）
  4. 对log4j2不熟悉，不能随心所欲的进行配置，这个必须花时间去学习。

总结

  1. 其实我也没有办法，最近的这段时间里，我根本没有搭起自己服务端环境，所以相关技术学习动力不够强。
  2. 我可能不想再花太多时间在前端学习上了，我自己想要的编辑器，固然很酷炫，但是工作做的不够好，也不行啊