我不清楚为什么我们既需要session.timeout.ms
和max.poll.interval.ms
我们何时会使用一个或另一个或两者兼而有之?似乎这两个设置都指示协调器在假设其死机之前将等待从消费者那里获取心跳的时间上限。
另外,对于基于KIP-62的0.10.1.0+版本,它的行为如何?
Answers:
在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
检测一下即可。
这样做的想法是,即使处理本身花费很长时间,也可以快速检测出失败的消费者。
max.poll.interval.ms
作为kafka v 0.10.1的一部分引入的事实尚不清楚。但是,在这种情况下,session.timeout.ms
可以将其替换heartbeat.interval.ms
为后者,因为后者显然暗示了它的含义或其中至少一个应该消失了?
session.timeout.ms
出于向后兼容的原因而保留是一个不错的选择。而且“ heartbeat.interval.ms”不是完美的,因为它并不表示存在超时。也许“ heartbeat.max.interval.ms”会更好(仍然,在参数名称中使用“ timeout”是语义的重要指示,并且会丢失。)
max.poll.interval.ms
对主处理线程进行一次健康检查-具有两个配置,可让您快速检测“硬故障”(心跳和主线程死亡),并简化代码以进行长时间处理(通过单个配置,您可以较长的拘留时间或复杂的代码会在“手动”处理期间触发心跳)