我们开始使用 Kafka 流，我们的服务是一个非常简单的无状态消费者。
我们对延迟的要求很严格，当消费者组重新平衡时，我们面临着过高的延迟问题。在我们的场景中，重新平衡会相对频繁地发生：滚动更新代码、扩大/缩小服务、容器被集群调度程序洗牌、容器死亡、硬件故障。
我们所做的第一个测试是让一个由 4 个消费者组成的小型消费者组处理少量消息（1K/秒）并杀死其中一个；集群管理器（目前是 AWS-ECS，可能很快就会转向 K8S）启动一个新的集群管理器。因此，进行了不止一次的重新平衡。
我们最关键的指标是延迟，我们将其衡量为发布者中的消息创建和订阅者中的消息消费之间的毫秒数。我们发现最大延迟从几毫秒飙升至近 15 秒。
我们还进行了一些滚动更新代码的测试，但结果更糟，因为我们的部署没有为 Kafka 服务做好准备，并且触发了很多重新平衡。我们需要解决这个问题，但想知道其他人在以尽可能小的延迟进行代码部署/自动扩展时遵循的策略是什么。
不确定它是否有帮助，但我们对消息处理的要求相当宽松：我们不关心某些消息不时被处理两次，或者对消息的顺序非常严格。
我们使用所有默认配置，没有进行任何调整。
我们需要改善重新平衡期间的延迟峰值。
有人可以给我们一些关于如何处理它的提示吗？触摸配置就够了吗？我们需要使用一些具体的分区分配器吗？实施我们自己的？
以尽可能最小的延迟进行代码部署/自动扩展的推荐方法是什么？
我们的Kafka版本是1.1.0，在查看了例如kafka/kafka_2.11-1.1.0-cp1.jar的库后，我们安装了Confluence平台4.1.0。
在消费者方面，我们使用Kafka-streams 2.1.0。
感谢您阅读我的问题和您的回复。
如果差距主要是由重新平衡引入的，意味着不触发重新平衡，而是让 AWS / K8s 继续工作并恢复弹回的实例并支付弹跳期间的不可用时间 --- 请注意，对于无状态实例，这通常更好，而对于有状态应用程序，您最好确保重新启动的实例可以访问其关联的存储，以便可以节省从更改日志进行引导的时间。
要做到这一点：
在 Kafka 1.1 中，为了减少不必要的重新平衡，您可以增加组的会话超时，以便协调器对未通过心跳响应的成员变得“不那么敏感”——请注意，我们从 0.11.0 开始为 Streams 禁用了 Leave.group 请求'消费者（https://issues.apache.org/jira/browse/KAFKA-4881 https://issues.apache.org/jira/browse/KAFKA-4881）因此，如果我们的会话超时时间较长，则离开组的成员不会触发重新平衡，但成员重新加入仍会触发重新平衡。不过，少一次重新平衡总比没有好。
不过，在即将到来的 Kafka 2.2 中，我们在优化重新平衡场景方面做了很大的改进，主要体现在 KIP-345 中（https://cwiki.apache.org/confluence/display/KAFKA/KIP-345%3A+Introduce+static+membership+protocol+to+reduce+consumer+rebalances https://cwiki.apache.org/confluence/display/KAFKA/KIP-345%3A+Introduce+static+membership+protocol+to+reduce+consumer+rebalances）。通过 KIP-345 中引入的合理配置设置，滚动反弹会触发更少的重新平衡。所以我强烈建议您升级到2.2，看看它是否对您的情况有帮助
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
