Kafka> = 0.10.1的session.timeout.ms和max.poll.interval.ms之间的差异


78

我不清楚为什么我们既需要session.timeout.msmax.poll.interval.ms我们何时会使用一个或另一个或两者兼而有之?似乎这两个设置都指示协调器在假设其死机之前将等待从消费者那里获取心跳的时间上限。

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


1
这仅适用于Kafka Connect吗?
Jacek Laskowski

Answers:


177

在KIP-62之前,只有session.timeout.ms(即Kafka0.10.0和更早版本)。max.poll.interval.ms是通过KIP-62(Kafka的一部分0.10.1)引入的。

KIP-62poll()通过后台心跳线程将心跳与呼叫分离,从而允许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检测一下即可。

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


感谢Matthias,这消除了很多混乱。max.poll.interval.ms作为kafka v 0.10.1的一部分引入的事实尚不清楚。但是,在这种情况下,session.timeout.ms可以将其替换heartbeat.interval.ms为后者,因为后者显然暗示了它的含义或其中至少一个应该消失了?
Deeps

如果您有这样的要求,则需要写到Kafka dev邮件列表。这是社区的决定...但是我想,session.timeout.ms出于向后兼容的原因而保留是一个不错的选择。而且“ heartbeat.interval.ms”不是完美的,因为它并不表示存在超时。也许“ heartbeat.max.interval.ms”会更好(仍然,在参数名称中使用“ timeout”是语义的重要指示,并且会丢失。)
Matthias J. Sax

@ MatthiasJ.Sax我有一个类似的问题,基于session.timeout.ms这个问题,我的消费者在提交偏移量时给出了异常。我想看看你能不能帮到我。

@ MatthiasJ.Sax,我仍然不清楚为什么我们需要两者。让我们说,消费者的工作花费很长时间来消费一条消息。例如,消费者通过非常慢的休息呼叫将消息发送给第三方。消费者仍可以使用后台线程定期将心跳发送给经纪人。max.poll.interval.ms似乎是多余的。
Daya

6
假设您的消费者死亡(或者存在一个无限循环的错误),但是后台线程一直在跳动。对于这种情况,不会有任何进展,但不会被发现。因此,max.poll.interval.ms对主处理线程进行一次健康检查-具有两个配置,可让您快速检测“硬故障”(心跳和主线程死亡),并简化代码以进行长时间处理(通过单个配置,您可以较长的拘留时间或复杂的代码会在“手动”处理期间触发心跳)
Matthias J. Sax
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.