这是对我之前发送的有关我们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秒多一点。
我们还测试了通过“杀死-9”非优雅地杀死消费者；结果是触发重新平衡的时间完全相同。
所以我们有一些问题： -我们期望当消费者正常停止时，立即触发重新平衡，这应该是预期的行为吗？为什么在我们的测试中没有发生？ -如何减少消费者正常退出与触发重新平衡之间的时间？权衡是什么？更多不需要的平衡？
有关更多信息，我们的Kafka版本为1.1.0，在查看例如kafka / kafka_2.11-1.1.0-cp1.jar的库之后，我们安装了Confluent平台4.1.0。在消费者方面，我们使用的是Kafka-streams 2.1.0。
谢谢！
答案 0 :(得分：0)
当实例正常关闭时，Kafka Streams不会发送“离开组请求”-这是有意的。目的是避免实例反弹（例如，一个实例升级一个应用程序；或者一个实例在Kubernetes环境中运行并且POD自动快速重启）时避免昂贵的重新平衡。
为此，使用了非公共配置。您可以通过
覆盖配置$query->execute(array(':username' => $username, ':password' => $user_input_hashed_password));