在 Kafka Streams 中重新平衡期间重建状态存储之前，分区处理卡住

Question

假设我有一个有状态的 Kafka Streams 应用程序，它使用来自具有 3 个分区的主题的数据。 目前我有 2 个运行上述应用程序的实例。 让我们这样说： instance1有分区part1和part2分配， instance2有part3 。

所以现在我想添加新实例以完全利用并行化。

据我了解，一旦我启动一个新实例，就会发生重新平衡：分区part1或part2和相应的本地状态存储将从现有实例迁移到新添加的实例。 在这个例子中，让我们假设part1在instance3迁移。

同时，我意识到新实例instance3在从变更日志主题恢复本地状态存储之前不会开始处理新数据，这可能需要很多时间。

从启动应用程序到恢复状态存储期间：

• 这是否意味着在instance3完成启动之前， part1中的数据不会被处理和卡住？
• 如果是，那么估计instance3构建本地状态存储需要多长时间的方法是什么？
• 在此期间，其他实例是否不受重新平衡的影响并在不停机的情况下继续处理数据（ instance1 - part2 , instance2 - part3 ）？

Answer 1

添加新实例时的重新平衡是在消费者组级别。 这意味着分配给消费者组的所有消费者的所有分区将被撤销，然后重新分配。 因此，所有分区 - 第 1 部分、第 2 部分和第 3 部分将被卡住，直到重新平衡完成。

现在估计停机时间有点棘手。 您可以在重新平衡触发器和消耗开始时发出事件 - 然后计算两个事件之间的时间差以获得停机时间的估计值。 如果您有一个简单的 Java 消费者日志，您还可以得到一个粗略的估计，因为所有相关日志（撤销的分区以及分配的分区）都已经存在。

Answer 2

重新平衡随着最近的发布而发展：

从带有KIP-429 的2.4.0 版开始

• 添加了增量合作重新平衡而不是停止世界重新平衡协议
• 针对云进行了优化，以便更好地重新平衡掉队成员的行为（例如，当 Pod 死亡并重新启动时）
• 如果组协调器再次将同一分区重新分配给消费者，则消费者不需要撤销分区

=> part2和part3没有卡住，继续加工

从带有KIP-441 的2.6.0 版开始

• 改进 Kafka Streams 扩展行为，特别是对于有状态任务
• 以前一些任务在处理中被阻止，直到状态存储被重建，这可能需要几个小时
• 现在新实例首先尝试从更改日志中追赶状态存储，然后才将任务视为活动
• 在横向扩展期间没有停机时间

=> part1继续在instance1上处理，直到instance3重建part1的状态存储并准备移交其处理