Java Kafka Streams重新平衡高吞吐量Kafka Streams服务的延迟峰值

我们开始使用Kafka streams，我们的服务是一个非常简单的无状态消费者

我们对延迟有严格的要求，当消费者群体重新平衡时，我们面临着太高的延迟问题。在我们的场景中，重新平衡将相对频繁地发生：滚动代码更新、放大/缩小服务、容器被集群调度器洗牌、容器死亡、硬件故障

我们所做的第一个测试之一是有一个小的消费者群体，其中4个消费者处理少量消息（1K/秒），并杀死其中一个；群集管理器（目前为AWS-ECS，可能很快将迁移到K8S）启动一个新的群集管理器。因此，不止一次的再平衡已经完成

我们最关键的度量是延迟，我们将其度量为发布服务器中的消息创建和订阅服务器中的消息消耗之间的毫秒。我们看到最大延迟从几毫秒增加到近15秒

我们还对一些滚动更新的代码进行了测试，结果更糟，因为我们的部署没有为Kafka服务做好准备，我们触发了很多重新平衡。我们需要做这方面的工作，但想知道其他人在尽可能减少延迟的情况下执行代码部署/自动缩放的策略是什么

不确定这是否有帮助，但我们对消息处理的要求非常宽松：我们不关心某些消息会不时被处理两次，或者对消息的顺序要求非常严格

我们使用的是所有默认配置，无需调整

我们需要在重新平衡期间改善这种延迟峰值。 有人能给我们一些关于如何操作的提示吗？触摸配置是否足够？我们需要用一些混凝土分区吗？实现我们自己的

在尽可能减少延迟的情况下，推荐的代码部署/自动缩放方法是什么

我们的卡夫卡版本是1.1.0，在查看了找到的libs（例如卡夫卡/Kafka_2.11-1.1.0-cp1.jar）之后，我们安装了Confluent platform 4.1.0。 在消费者方面，我们使用Kafka streams 2.1.0

---

感谢您阅读我的问题和您的回答。

如果差距主要是由重新平衡引起的，也就是说，不触发重新平衡，只是让AWS/K8s做他们的工作，恢复被反弹的实例，并在反弹期间支付不可用时间段的费用---注意，对于无状态实例，这通常更好，而对于有状态的应用程序，您最好确保重新启动的实例可以访问其关联的存储，以便在从changelog引导时进行保存

为此：

在Kafka 1.1中，为了减少不必要的重新平衡，您可以增加组的会话超时，以便协调器对没有心跳响应的成员变得“不那么敏感”——请注意，我们从0.11.0开始为Streams的消费者（）禁用了leave.group请求，因此如果会话超时更长，离开集团的成员不会触发再平衡，尽管重新加入集团的成员仍会触发再平衡。不过，少一次再平衡总比没有好

---

不过，在即将发布的卡夫卡2.2中，我们在优化再平衡场景方面做了很大改进，主要在KIP-345（）中捕获。随着KIP-345中引入合理的配置设置，滚动弹跳将触发更少的再平衡。因此，我强烈建议您升级到2.2，看看它是否有助于您的案例

谢谢王国章，关于Kafka 1.1的建议解决方案，增加会话超时将有助于我们避免重新平衡，但代价是一些分区（分配给死掉的消费者的分区）会过时较长时间。相反，减少会话超时的利/弊是什么？因为您的应用程序是无状态的，这可能更可取：重新平衡的主要成本是所花费的任务迁移和相应的任务恢复时间，但对于无状态的应用程序，这样的时间应该很短，因此，减少会话超时，让协调器更加敏感，并更快地触发重新平衡。如果您不介意，请共享您的grafana仪表板好吗？如何导出it所需的数据？在这种情况下，备用副本是否有帮助？根据文档，备用副本旨在加快有状态服务的恢复速度。由于我们的服务是无状态的，所以我们遇到的问题是重新平衡的滞后，不涉及状态迁移。所以，我认为备用副本不会有任何帮助。@jarias正如Ankur所问的，请分享仪表板，以及您是如何导出这些数据的？在我们的案例中，我们使用客户端度量来重新平衡。我不知道能否从经纪人那里得到。我们使用ConsumerBalanceListener报告指标：