Kafka-streams 延迟启动消费者优雅关闭的重新平衡答案

【问题标题】：Kafka-streams delay to kick rebalancing on consumer graceful shutdownKafka-streams 延迟启动消费者优雅关闭的重新平衡
【发布时间】：2019-06-21 06:20:53
【问题描述】：

这是对我之前发送的关于 Kafka Streams 中的高延迟问题的跟进； (Kafka Streams rebalancing latency spikes on high throughput kafka-streams services)。

快速提醒一下，我们的无状态服务有非常严格的延迟要求，我们面临着延迟太高的问题（有些消息在生成后消耗超过 10 秒），特别是当消费者优雅地离开组时。

经过进一步调查，我们发现至少对于小型消费者群体而言，重新平衡所需的时间不到 500 毫秒。所以我们想，当移除一个消费者（>10s）时，这个巨大的延迟来自哪里？

我们意识到这是消费者优雅退出和重新平衡开始之间的时间。

之前的测试是在 Kafka 和 Kafka Streams 应用程序中使用所有默认配置执行的。我们将配置更改为：

properties.put("max.poll.records", 50); // defaults to 1000 in kafkastreams
properties.put("auto.offset.reset", "latest"); // defaults to latest
properties.put("heartbeat.interval.ms", 1000);
properties.put("session.timeout.ms", 6000);
properties.put("group.initial.rebalance.delay.ms", 0);
properties.put("max.poll.interval.ms", 6000);

结果是重新平衡开始的时间下降到 5 秒多一点。

我们还测试了通过“kill -9”来非优雅地杀死消费者；结果就是触发rebalance的时间完全一样。

所以我们有一些问题： - 我们预计，当消费者优雅地停止时，重新平衡会立即触发，这应该是预期的行为吗？为什么在我们的测试中没有发生？ - 我们如何减少消费者优雅退出和触发再平衡之间的时间？有什么权衡？更多不需要的再平衡？

关于更多上下文，我们的 Kafka 版本是 1.1.0，在查看了例如 kafka/kafka_2.11-1.1.0-cp1.jar 的库后，我们安装了 Confluent 平台 4.1.0。在消费者方面，我们使用的是 Kafka-streams 2.1.0。

谢谢！

【问题讨论】：

标签： java apache-kafka apache-kafka-streams

【解决方案1】：

当实例正常关闭时，Kafka Streams 不会发送“离开组请求”——这是故意的。目标是避免在实例被退回时进行昂贵的重新平衡（例如，如果一个应用程序升级；或者如果一个在 Kubernetes 环境中运行并且 POD 会自动快速重启）。

为此，使用了非公开配置。您可以通过

覆盖配置

props.put("internal.leave.group.on.close", true); // Streams' default is `false`

【讨论】：

谢谢马蒂亚斯！你知道为什么这是一个非公开的配置吗？使用我们可以依赖的非公共配置吗？
将其公开存在疑虑。参照。 issues.apache.org/jira/browse/KAFKA-6995 -- 如果你使用它，你应该在升级之前仔细检查配置是否仍然存在，如果不存在，可能会产生什么影响——因为它是非公开的，显然不会在发行说明中提及。
那么，结合这个和增量协作重新平衡，它会避免重新平衡反弹 pod 上分配的分区（包括重状态存储支持分区）吗？我之所以问这个问题是因为我看到 2.7.0 KStream 应用程序中发生了一些重新平衡，这些应用程序具有大量的状态存储。另外，我想知道是不是因为那些是备用的复制品……
是的，我可以降低风险，但这也取决于您的配置。不过，您可能还想检查静态组成员身份，这应该会有所帮助。