库伯内特的Kafka流：重新部署后的长期再平衡

Question

我们使用StatefulSet在Kubernetes上部署Scala Kafka Streams应用程序。实例具有单独的applicationids，因此它们每个都复制完整的输入主题，以实现容错。它们本质上是只读服务，只读取一个状态主题并将其写入状态存储，客户请求通过REST从那里得到服务。这意味着，在任何给定时间，消费者组总是仅由单个Kafka Streams实例组成。

现在我们的问题是，当触发滚动重启时，每个实例大约需要5分钟才能启动，其中大部分时间花费在rebalancing状态中等待。我在这里读到过，Kafka Streams不会发送LeaveGroup请求，以便在容器重新启动后快速返回，而不会重新平衡。为什么这对我们不起作用，为什么即使applicationid是相同的，重新平衡也需要这么长的时间？理想情况下，为了最大限度地减少停机时间，应用程序应该从重新启动时离开的地方立即接管。

properties.put(StreamsConfig.consumerPrefix(ConsumerConfig.MAX_POLL_RECORDS_CONFIG), "1000")
properties.put(StreamsConfig.consumerPrefix(ConsumerConfig.SESSION_TIMEOUT_MS_CONFIG), "300000")
properties.put(StreamsConfig.consumerPrefix(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG), "earliest")
// RocksDB config, see https://docs.confluent.io/current/streams/developer-guide/memory-mgmt.html
properties.put(StreamsConfig.ROCKSDB_CONFIG_SETTER_CLASS_CONFIG, classOf[BoundedMemoryRocksDBConfig])    

• 减少会话.timeout.ms会有帮助吗？我们将其设置为相当大的值，因为Kafka代理居住在不同的数据中心，网络连接有时不是超级可靠的。
• 此答案建议减少max.poll.interval.ms，因为它与重新平衡超时有关。那是正确的吗？我在犹豫是否要改变这个，因为它可能会对我们应用程序的正常操作模式产生影响。
• 提到了一个config组.initial.rebalance.delay.ms来延迟部署期间的重新平衡-但这也会在从崩溃中恢复后导致延迟，是吗？
• 我还偶然发现了KIP-345，它的目标是完全通过group.instance.id来消除静态成员身份的消费者再平衡，这将非常适合我们的用户案例，但它似乎还没有在我们的代理上提供。

我对众多的配置以及如何使用它们来实现更新后的快速恢复感到困惑。有人能解释一下他们是怎么一起玩的吗？

Answer 1

你提到的另一个问题并不是说在重启时避免了再平衡。不发送leavegrouprequest只会避免停止应用程序时的重新平衡。因此，再平衡的次数从两次减少到一次。当然，对于您的有点不同寻常的单实例部署，您在这里没有任何收获（事实上，它实际上可能“伤害”您……)

减少session.timeout.ms会有帮助吗？我们将其设置为相当大的值，因为Kafka经纪人生活在不同的数据中心，网络连接有时不是超级可靠的。

可能是，这取决于你重启应用程序的速度。（详细信息请参阅下文。）也许只是尝试一下（例如，设置为3分钟，仍然有一个高值的稳定性，并看到它的再平衡时间下降到3分钟？

max.poll.interval.ms也会影响再平衡时间（更多详细信息见下文）。但是，默认值为30秒，因此不应导致5分钟的重新平衡时间。

这里提到了配置组p.initial.rebalance.delay.ms来延迟部署期间的重新平衡--但这也会在从崩溃中恢复后导致延迟，不是吗？

这只适用于空消费者组，默认值仅为3秒。所以应该不会影响你。

我还偶然发现了KIP-345，它的目标是完全通过group.instance.id来消除静态成员身份的消费者再平衡，这将非常适合我们的用户案例，但它似乎还没有在我们的代理上提供。

使用静态组成员身份实际上可能是最好的选择。也许值得升级您的代理以获得此功能。

顺便说一句，session.timeout.ms和max.poll.interval.ms之间的差异在另一个问题中解释：对于Kafka 0.10.0.0和更高版本，session.timeout.ms和max.poll.interval.ms之间的差异

通常，代理端组协调器维护每个“组生成”的所有成员的列表。如果成员主动离开组（通过发送leaveGroupRequest)、超时（通过session.timeout.ms或max.poll.interval.ms)或新成员加入组，则会触发重新平衡。如果发生了重新平衡，每个成员都有机会重新加入小组，以纳入下一代。

对于您的情况，小组只有一个成员。停止应用程序时，不会发送LeaveGroupRequest，因此组协调器将仅在session.timeout.ms通过后删除此成员。

如果你重新启动应用程序，它会作为一个“新”成员回来（从组协调者的角度来看）。这将触发一个重调，给组中的所有成员一个重新加入组的改变。对于您的情况，“旧的”实例可能仍在组中，因此只有在组协调器将旧成员从组中移除后，再平衡才会向前移动。问题可能是，小组协调员认为小组从一个成员扩大到两个成员。（这就是我上面的意思：如果将发送leavegrouprequest，那么当您停止应用程序时，组将变为空的，并且在重新启动时，只有新成员在组中，并且重新平衡将立即向前移动。）

使用静态组成员身份可以避免这个问题，因为在重新启动时，实例可以被重新标识为“旧的”实例，并且组协调器不需要等待旧的组成员过期。