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

Question

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

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

我们完成的第一个测试之一是让一个由4个消费者组成的小型消费者组处理少量的消息(1K/秒)并杀死其中的一个；集群管理器(目前是AWS-ECS，可能很快就会转移到K8S)启动一个新的。因此，不止一次完成了重新平衡。

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

​

​

​

​

​

​

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

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

我们使用所有的默认配置，没有调整。

我们需要在重新平衡期间改善这种延迟峰值。有人能给我们一些关于如何工作的提示吗？接触配置就足够了吗？我们需要使用一些具体的部分吗？实现我们自己的？

推荐的代码部署/自动伸缩方法是什么，并且尽可能减少延迟？

我们的Kafka版本是1.1.0，在查看了kafka/kafka_2.11-1.1.0-cp1.jar等库之后，我们安装了Confluent platform 4.1.0。在消费者端，我们使用的是Kafka-streams 2.1.0。

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

Answer 1

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

为此，请执行以下操作：

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

在即将到来的Kafka 2.2中，我们在优化重新平衡场景方面做了很大的改进，主要是在KIP-345 (https://cwiki.apache.org/confluence/display/KAFKA/KIP-345%3A+Introduce+static+membership+protocol+to+reduce+consumer+rebalances)中捕获的。使用KIP-345中引入的合理配置设置，滚动反弹将触发更少的再平衡。因此，我强烈建议您升级到2.2，看看它是否对您的情况有帮助

Answer 2

需要进行多项配置更改才能显著减少重新平衡延迟，尤其是在部署部署期间

Kafka 1.保留最新版本的-Streams

随着时间的推移，Kafka-Streams的重新平衡性能变得越来越好。值得强调的一个特性改进是Incremental cooperative rebalancing protocol。Kafka-Streams有这个开箱即用的特性(从2.4.0版本开始，在2.6.0版本中做了一些改进)，带有默认的分区分配器StreamsPartitionAssignor。

2.添加Kafka-Streams配置属性 internal.leave.group.on.close = true ，用于在应用关闭时发送消费者离开组请求

默认情况下，Kafka-Streams不会在app正常关机时发送消费者离开群组请求，因此，来自某些分区(分配给正在销毁的应用实例)的消息将不会被处理，直到该消费者的session过期(持续时间为session.timeout.ms)，并且只有在过期后，才会触发新的rebalance。为了改变这种默认行为，我们应该使用内部的Kafka Streams配置属性internal.leave.group.on.close = true (这个属性应该在Kafka Streams创建new KafkaStreams(streamTopology, properties)时添加)。由于该属性是私有的，因此在升级到新版本之前，如果配置仍然存在，请小心并仔细检查。

3.减少部署期间同时重启的应用实例数量

使用Kubernetes，我们可以控制使用新部署同时创建多少个应用程序实例。这可以通过使用属性max surge和max unavailable来实现。如果我们有数十个应用程序实例，默认配置将推出多个新实例，同时，多个实例将终止。这意味着多个分区将需要重新分配到其他应用实例，并且将触发多个重新平衡，这将导致显著的重新平衡延迟。减少重新平衡持续时间的最可取配置是将这些配置更改为max surge = 1和max unavailable = 0。

4.增加略多的主题分区和app实例数量

分区数量越多，每个分区的吞吐量就越低。此外，由于应用实例数量较多，重启单个应用实例将导致重新平衡时的Kafka延迟较小。此外，请确保您不会频繁地放大和缩小应用程序实例(因为这会触发重新平衡)。如果你每小时有几次扩容和缩容，对于最少的实例来说，这似乎不是一个好的配置，所以你需要增加它。

有关更多详细信息，请查看文章Kafka-Streams - Tips on How to Decrease Re-Balancing Impact for Real-Time Event Processing On Highly Loaded Topics