在Kafka Streams中重新平衡期间，分区处理一直停滞，直到重建状态存储
假设我有有状态的 Kafka Streams 应用程序，该应用程序使用具有 3 个分区的主题中的数据。目前，我正在运行上述应用程序的2个实例。让我们这样说：实例 1 分配了分区 part1 和 part2，实例 2 分配了 part3。
因此，现在我想添加新实例，以完全利用并行化。
在我的理解中，一旦我启动了一个新实例，就会发生重新平衡：分区 part1 或 part2 中的一个以及相应的本地状态存储将从现有实例迁移到新添加的实例。在此示例中，让我们假设 part1 在实例 3 上迁移。
同时，我意识到，新实例instance3在从changelog主题恢复本地状态存储之前不会开始处理新数据，这可能需要很多时间。
从启动应用程序到恢复状态存储的时间段内：
- 这是否意味着
part1中的数据在实例3 如果是，那么用什么方法来估计instance3构建本地状态存储需要多少时间在此期间，其他实例是否不受重新平衡的影响，并在不停机的情况下继续处理数据（instance1-part2、instance2-part3>）
共有2个答案
添加新实例后的重新平衡是在消费者组级别。这意味着分配给消费者组所有消费者的所有分区都将被撤销，然后重新分配。因此，所有分区-part1、part2和part3将被卡住，直到重新平衡完成。
现在估计停机时间有点棘手。您可以在重新平衡触发器和消耗开始时发出事件——然后计算两个事件之间的时间差以获得停机时间的估计。如果您有一个简单的java消费者日志，您也可以得到一个粗略的估计，因为所有相关的日志（撤销的分区以及分配的分区）都已经存在。
重新平衡随着最近的版本而发展：
从版本 2.4.0 与 KIP-429
- 添加了增量合作再平衡，而不是停止世界再平衡协议
- 针对云进行了优化，可以更好地重新平衡掉落成员的行为（例如，当Pod已死并重新启动时）
- 如果组协调器再次将同一分区重新分配给消费者，则消费者不需要撤销分区
=
从带有KIP-441的版本2.6.0开始
- 改进 Kafka 流向外扩展行为，特别是对于有状态任务
- 以前，某些任务在处理过程中被阻止，直到重建状态存储，这可能需要数小时
- 现在，新实例首先尝试从更改日志中追赶状态存储，然后才将任务视为活动状态
- 横向扩展期间无停机时间
=
-
到目前为止，我能找到的唯一解决办法是在发送数据后总是断开与服务器端的连接，并且在我的代码中，将整个包装在一个循环中，类似于 以便在服务器发送一些数据并断开客户端连接后立即启动新的连接。
-
我发现分区“Tracking-3”上的消息没有被消耗！！ 问题每次都会重现，在新分配的分区中有一些消息丢失，你能有什么建议吗？请帮帮我，谢谢
-
我遇到了一件关于Kafka再平衡的奇怪事情。如果我增加某个主题的分区，而该主题是由一些java使用者（在同一个组中）订阅的，则不会发生使用者再平衡。在那之后，我试图通过启动一个新的消费者（或杀死一个消费者）来实现重新平衡，但在这个重新平衡中无法分配新增加的分区。我发现只有在停止所有使用者并启动它们之后，才能分配新分区。我不知道这是正常还是有任何解释。 下面是我在电脑上的测试： 1.启动Kafka，
-
问题内容： 我有一个数据块，当前为n元组列表，但格式相当灵活，我想附加到Postgres表中-在这种情况下，每个n元组都对应于数据库中的一行。 到目前为止，我一直在做的工作是将所有内容都写入CSV文件，然后使用postgres的COPY将所有内容批量加载到数据库中。这可行，但不是最佳选择，我希望能够直接从python进行所有操作。python中是否有一种方法可以在Postgres中复制COPY类型
-
问题内容： 我是Redis的新手，我想知道是否有一种方法可以 通过键的值来获取值，直到键存在为止。最小代码： 如你所知，如果这种犯规存在，它的。但是由于在我的项目中，将键值对与redis绑定发生在另一个应用程序中，因此我希望redis_connection 方法能够阻止直到key存在。这样的期望是否有效？ 问题答案： 如果不在客户端上实现某种池化 redis GET， 就无法做您想做的事情。在这种
-
本文向大家介绍消费组与分区重平衡相关面试题，主要包含被问及消费组与分区重平衡时的应答技巧和注意事项，需要的朋友参考一下 当有新的消费者加入到消费者组时，原本的分区就需要重新分配；比如一个topic有30个分区，原本只有两个消费者，每人负责15个分区，当新加入一个消费者时，并没有分区可以给他消费，只能是将30个分区重新分配。 每个消费者组都会有一个broker负责协调（称为group coordin