【问题标题】:Kafka Consumer group rebalancingKafka消费者组再平衡
【发布时间】:2020-06-30 08:35:05
【问题描述】:

我正在使用 kafka 消费者组管理来处理我的消息。

我的消息的处理时间各不相同。因此,我将最大轮询间隔设置为 20 分钟,最大记录为 20。我使用 5 个分区和 5 个消费者实例,默认配置值与上述两个不同。

但我仍然间歇性地收到以下错误:

[Consumer clientId=consumer-3, groupId=amc_dashboard_analytics] Attempt to heartbeat failed since group is rebalancing

理解是,除非在达到消费者配置文档中所写的最大轮询间隔之前未调用轮询,否则不会发生重新平衡。但对我来说,重新平衡只发生在 20 分钟之前。

同样经过几个小时的运行,所有分配的消费者只是离开说“尝试心跳失败,因为组正在重新平衡”并且不再加入(理想情况下应该再次加入)。

我在这里遗漏了什么吗?任何线索都会有所帮助。

【问题讨论】:

  • 心跳是检查所有消费者是否仍在运行的基本机制。如果由于组正在重新平衡而导致心跳失败,
  • 这表明您的消费者实例发送下一个心跳的时间过长,被认为已死,因此触发了重新平衡
  • @DeV 但是为什么发送心跳需要时间。我读到的是消费者继续在与最大轮询间隔处理线程分开的并行线程中发送心跳。
  • 消费者加入或离开群组时也会发生重新平衡。
  • @Nobita 我添加了一些无法向代理发送心跳的可能原因。你可以看看我的回答。

标签: apache-kafka kafka-consumer-api


【解决方案1】:

再平衡的另一个原因是到期session.timeout.ms 没有发送心跳。你可以考虑增加这个消费者配置。

来自 Kafka 文档:

heartbeat.interval.ms:心跳到 使用 Kafka 的组管理设施时的消费者协调员。 心跳用于确保消费者的会话保持活动状态 并在新消费者加入或离开时促进再平衡 团体。该值必须设置为低于 session.timeout.ms,但是 通常应设置为不高于该值的 1/3。有可能 调整得更低以控制正常的预期时间 再平衡。 (默认:3000)


session.timeout.ms:用于检测客户端故障的超时时间 使用 Kafka 的组管理工具。客户端定期发送 心跳以向代理指示其活跃性。如果没有心跳 在此会话到期之前由经纪人收到 超时,则代理将从组中删除该客户端,并 启动再平衡。请注意,该值必须在允许范围内 代理配置中配置的范围 group.min.session.timeout.ms 和 group.max.session.timeout.ms。 (默认:10000)

您可以查看此link 了解更多信息。

即使通过单独的线程以固定的时间间隔发送心跳,在某些情况下也无法将心跳发送到session.timeout.ms 中的代理。这种情况的一些可能原因是:

  • 网络问题
  • 在消费者或代理端停止世界垃圾收集

【讨论】:

  • 什么是“stop-the-world 垃圾回收”?
  • @Nobita "Stop-the-world 表示 JVM 正在停止应用程序运行以执行 GC。当 stop-the-world 发生时,除了 GC 所需的线程之外的每个线程都会停止他们的任务。被中断的任务只有在 GC 任务完成后才会恢复。GC 调整通常意味着减少这个 stop-the-world 时间。 link
  • 记忆也可能是心跳失败的原因吗?
  • @Nobita 是的。我在生产中遇到过这种情况。如果 JVM (-XmX) 使用的内存不够,会导致更频繁的 GC。并且在 GC 期间,包括心跳在内的线程无法按预期运行。我建议您使用此 JVM 选项监视 GC 日志以确保:`-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/to/file.txt>`答案中提到,我的建议是简单地增加session.timeout.ms 作为解决方法,直到诊断出主要原因。
  • 我应该在什么基础上设置 session.timeout.ms 的值,理想值是多少?
猜你喜欢
  • 2015-04-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-08-08
  • 2015-01-26
  • 2017-06-19
  • 1970-01-01
相关资源
最近更新 更多