【问题标题】:Difference between session.timeout.ms and max.poll.interval.ms for Kafka >= 0.10.1Kafka >= 0.10.1 的 session.timeout.ms 和 max.poll.interval.ms 之间的差异
【发布时间】:2017-02-05 09:47:30
【问题描述】:

我不清楚为什么我们需要 session.timeout.msmax.poll.interval.ms 以及我们什么时候使用其中一个或两个?似乎这两个设置都表示协调器在假设消费者死亡之前等待从消费者那里获取心跳的时间上限。

此外,基于KIP-62 的版本 0.10.1.0+ 的行为如何?

【问题讨论】:

  • 这仅适用于 Kafka Connect 吗?

标签: apache-kafka kafka-consumer-api


【解决方案1】:

在 KIP-62 之前,只有 session.timeout.ms(即 Kafka 0.10.0 及更早版本)。 max.poll.interval.ms 是通过KIP-62 介绍的(Kafka 的一部分0.10.1)。

KIP-62,通过后台心跳线程将心跳与对poll() 的调用分离,允许比心跳间隔更长的处理时间(即两个连续的poll() 之间的时间)。

假设处理一条消息需要 1 分钟。如果心跳和轮询是耦合的(即在 KIP-62 之前),您需要将session.timeout.ms 设置为大于 1 分钟,以防止消费者超时。但是,如果有消费者死亡,也需要超过 1 分钟才能检测到失败的消费者。

KIP-62 将轮询和心跳分离,允许在两个连续轮询之间发送心跳。现在你有两个线程在运行,心跳线程和处理线程,因此,KIP-62 为每个线程引入了超时。 session.timeout.ms 用于心跳线程,max.poll.interval.ms 用于处理线程。

假设,您设置了session.timeout.ms=30000,因此,消费者心跳线程必须在此时间到期之前向代理发送心跳。另一方面,如果处理单个消息需要 1 分钟,您可以将max.poll.interval.ms 设置为大于 1 分钟,以给处理线程更多时间来处理消息。

如果处理线程死亡,则需要max.poll.interval.ms 才能检测到这一点。但是,如果整个消费者都死了(并且一个死去的处理线程很可能会导致包括心跳线程在内的整个消费者崩溃),那么只需要session.timeout.ms 就可以检测到它。

这个想法是,即使处理本身需要很长时间,也可以快速检测失败的消费者。

实现细节

新的超时max.poll.interval.ms主要是一个客户端的概念:如果poll()没有在max.poll.interval.ms内被调用,心跳线程会检测到这种情况并向broker发送一个离开组请求。 -- max.poll.interval.ms 仍然与消费者组重新平衡相关:如果触发重新平衡,消费者有max.poll.interval.ms 时间通过调用触发加入组请求的poll() 客户端重新加入组。

【讨论】:

  • 感谢马蒂亚斯,这消除了很多困惑。 max.poll.interval.ms 作为 kafka v 0.10.1 的一部分引入的事实并不明显。然而,在这种情况下,听起来像 session.timeout.ms 然后可以用 heartbeat.interval.ms 代替,因为后者清楚地暗示了它的含义,或者至少其中一个应该消失?
  • 如果你有这样的要求,你需要写信给 Kafka 开发邮件列表。这是一个社区决定......但我想,出于向后兼容性的原因保留session.timeout.ms 是一个不错的选择。而“heartbeat.interval.ms”并不完美,因为它并不表示涉及超时。也许“heartbeat.max.interval.ms”会更好(不过,在参数名称中使用“timeout”是语义的一个强有力的指标,并且会丢失。)
  • @MatthiasJ.Sax 我有一个基于session.timeout.ms 的类似question,其中我的消费者在提交偏移量时给出了异常。我想看看你能不能帮帮我。
  • 假设你的消费者死了(或者有一个无限循环的错误),但后台线程保持心跳。对于这种情况,这不会有任何进展,但不会被发现。因此,max.poll.interval.ms 是对您的主处理线程的健康检查——拥有两个配置,允许您快速检测“硬故障”(心跳和主线程都死),并简化您的代码以进行长时间处理(使用单个配置您在“手动”处理期间有很长的保留时间或复杂的代码来触发心跳)
  • 从技术上讲,如果您处理记录的时间超过max.poll.interval.ms(即,您没有在max.poll.interval.ms 内调用poll()),心跳威胁将停止发送心跳,但它会发送一个“离开组请求”以触发重新平衡。因此会话超时不适用于这种情况。 -- 对于 Kafka Streams,它更复杂 -- 在内部,KS 尝试定期调用 poll(),即使尚未处理所有记录,以避免退出组。 -- 心跳间隔是针对整个应用程序崩溃的情况。
猜你喜欢
  • 2020-05-19
  • 2017-10-14
  • 2020-02-18
  • 2018-09-30
  • 2017-10-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-02-13
相关资源
最近更新 更多