Apache kafka 卡夫卡消费者未能通过心跳后离开集团

我们正面临一系列卡夫卡消费者的问题。每当kafka集群上出现诸如重新启动代理（滚动重新启动）或重新启动运行代理的VM之类的活动时，我们的kafka消费者

LeaveGroup

就会在心跳失败后离开。下面的日志精确地重复了一分钟，并对应于应用程序代码中正在执行的

commitSync

调用，作为使用来自主题的消息的一部分

[Consumer clientId=consumer-13, groupId=delay-group-PostEnrollmentAppManagement] Offset commit failed on partition <topic-name> at offset 455700: The coordinator is loading and hence can't process requests.

在这之后，信息堆积在主题中，我们注意到滞后明显增加，没有消费者。我们重新启动承载消费者的应用程序，再次开始消费

我们能做些什么来避免这种情况？应用程序使用者端是否应该采取任何措施来处理此问题

---

注意：对于这个特定的消费者，我们使用了库。我们通常使用

springkafka

库来构建我们的消费者。我们使用apache one是因为我们想使用卡夫卡消费者的

暂停

和

恢复

功能，而在

春季卡夫卡

版本中不支持这些功能。当您提到您正在卡夫卡代理上执行活动，即重新启动虚拟机时，我们使用了这些功能（这些应该重新控制卡夫卡服务而不是容器）。我的意思是，即使在维护的时候，如果你想要不断的消耗，你也必须考虑下面的内容：

• 卡夫卡经纪人必须以滚动重新启动的方式撤下进行维护
• 建议每次进行一次以上操作，或根据群集配置中的ISR设置执行
• 分区数和复制系数必须大于1就好像代理因维护而停机一样，您的主题不应具有导致生产者/消费者故障并进而导致数据丢失的脱机分区

个人建议，在滚动重新启动中的最后一个控制器时，可以将控制器下拉，以避免多个控制器切换和重新加载群集元数据

当我们在维护活动之后对每个代理执行滚动重新启动时，代理需要一些时间才能启动，即重新填充分区元数据和所有复制不足的分区返回0所需的时间（这一点非常重要，以免多次重启给控制器带来压力，因为多个复制不足的分区会导致脱机/不可用的主题分区，具体取决于您的配置）

除此之外，您还可以调整以下消费者配置-

• heartbeat.interval.ms-必须低于session.timeout.ms
• session.timeout.ms
• 最大轮询间隔毫秒 以上内容可以根据您的连接延迟和kafka群集状态进行调整 你可以在网上阅读更多关于他们的信息

也可能在群集维护活动发生时，分配给分区负责人的代理需要时间来响应，这远远大于session.timeout.msmax.poll，在这种情况下，使用者停止重试。因此，调整使用者配置并在群集操作中保持健全性是最重要的健康持续的卡夫卡融合的关键*

注意-就个人而言，我们以超过1GPB的吞吐量完成了群集升级/维护活动，并且没有面临消耗问题（由于重新平衡，请求处理程序/网络处理程序延迟会出现峰值）。 仔细执行时牢记上述免责声明，更新更容易，但肯定很耗时，因为它们是以串行方式执行的

更多关于集群维护和消费者行为调整的文档帮助-

---

最终是root导致了问题。

kafkaConsumer#commitSync

抛出了一个未经检查的异常，

TimeOutException

，因为新的组协调器在遇到错误时，

commitSync

重试的一分钟内没有完成加载偏移量
我没有处理这个暂时性错误。导致调试困难的原因是我从主线程派生了一个线程的使用者。使用者线程中没有异常处理，也没有检查主线程中的未来对象。因此，

TimeOutException

也没有被记录

[Consumer clientId=consumer-13, groupId=delay-group-PostEnrollmentAppManagement] Attempt to heartbeat failed since group is rebalancing
[Consumer clientId=consumer-13, groupId=delay-group-PostEnrollmentAppManagement] Member consumer-13-837563e4-49e9-4bd1-aee4-cb21263e176a sending LeaveGroup request to coordinator <broker-host-name> (id: 2147483646 rack: null)
[Consumer clientId=consumer-13, groupId=delay-group-PostEnrollmentAppManagement] This member will leave the group because consumer poll timeout has expired. This means 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 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.