From feefa5c9c13dcc42e524905214c497f522153347 Mon Sep 17 00:00:00 2001 From: hmao Date: Sun, 23 Aug 2020 20:57:07 -0700 Subject: [PATCH] Update Kafka.md --- Kafka.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/Kafka.md b/Kafka.md index 271bf17..29f16c6 100644 --- a/Kafka.md +++ b/Kafka.md @@ -73,3 +73,18 @@ public interface ConsumerInterceptor extends Configurable { } ``` + +### Consumer Rebalance +第一类非必要 Rebalance 是因为未能及时发送心跳，导致 Consumer 被“踢出”Group 而引发的。因此，你需要仔细地设置 +session.timeout.ms 和 heartbeat.interval.ms 的值。我在这里给出一些推荐数值，你可以“无脑”地应用在你的生产环境中。 + +设置 session.timeout.ms = 6s + +设置 heartbeat.interval.ms = 2s + +要保证 Consumer 实例在被判定为“dead”之前，能够发送至少 3 轮的心跳请求，即 session.timeout.ms >= 3 * heartbeat.interval.ms。将 session.timeout.ms 设置成 6s 主要是为了让 Coordinator 能够更快地定位已经挂掉的 Consumer。毕竟，我们还是希望能尽快揪出那些“尸位素餐”的 Consumer，早日把它们踢出 Group。希望这份配置能够较好地帮助你规避第一类“不必要”的 Rebalance + + +第二类非必要 Rebalance 是 Consumer 消费时间过长导致的。我之前有一个客户，在他们的场景中，Consumer 消费数据时需要将消息处理之后写入到 MongoDB。显然，这是一个很重的消费逻辑。MongoDB 的一丁点不稳定都会导致 Consumer 程序消费时长的增加。此时，max.poll.interval.ms 参数值的设置显得尤为关键。如果要避免非预期的 Rebalance，你最好将该参数值设置得大一点，比你的下游最大处理时间稍长一点。就拿 MongoDB 这个例子来说，如果写 MongoDB 的最长时间是 7 分钟，那么你可以将该参数设置为 8 分钟左右 + +