0

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

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

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

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

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

  • 这是否意味着在完成启动part1之前没有处理并卡住来自的数据？instance3
  • instance3如果是，那么有什么方法可以估计建立当地的州立商店需要多少时间？
  • 在此期间，其他实例是否不受重新平衡的影响并继续处理数据而没有停机时间 ( instance1 - part2, instance2 - part3)？
4

2 回答 2

1

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

从带有KIP-429 的2.4.0 版开始

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

=>part2并part3没有卡住，继续处理

从带有KIP-441 的2.6.0 版开始

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

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

于 2021-11-25T09:38:19.377 回答
0

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

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

于 2021-11-08T16:10:16.967 回答