Kafka增量粘性再平衡
我用Kafka-斯特里姆齐算子在库伯内特斯上运行Kafka。我正在使用增量粘性再平衡策略，通过以下配置我的消费者：
ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG,
org.apache.kafka.clients.consumer.CooperativeStickyAssignor.class.getName()
每次我在我的消费者组中缩放消费者时，该组中的所有现有消费者都会生成以下异常
线程“main”组织中出现异常。阿帕奇。Kafka。常见的错误。RebalanceInProgressException：由于使用者正在进行自动分区分配的重新平衡，因此无法完成偏移量提交。您可以通过调用poll（）来尝试完成重新平衡，然后重试该操作
知道是什么导致了这个异常和/或如何解决它吗？
谢谢你。
共有1个答案
每当消费者组的元数据信息发生变化时，就会发生消费者再平衡。
在一个组中添加更多的消费者（用你的话说就是缩放）就是这样一个变化，并触发重新平衡。在这个变化过程中，每个消费者都将被重新分配分区，因此在重新分配完成之前不知道要提交哪些偏移量。现在，StickyAssignor确实尝试确保尽可能保留以前的分配，但是重新平衡仍然会被触发，甚至分区的分配也将优先于保留以前的分配。（参考-Kafka文档）
除此之外，异常的信息是不言自明的，即在重新平衡的过程中，一些操作是被禁止的。
如何避免这样的情况发生？
这是一个棘手的问题，因为Kafka需要重新平衡才能有效工作。有几种做法可以用来避免不必要的影响：
- 增加轮询时间-
max.poll.interval.ms-这样遇到这些异常的可能性就降低了。 - 减少投票记录的数量-
max.poll.recordsormax.partition.fetch.bytes - 尝试使用Kafka的最新版本（如果您使用旧版本，则进行升级），因为到目前为止，许多最新的升级都对重新平衡协议进行了改进
- 使用静态成员协议来减少再平衡
- 可能会考虑为空用户组配置
group.initial.rebalance.delay.ms（第一次部署或销毁所有内容并重新部署）
这些技术只能帮助您减少不必要的行为或异常，但不会完全阻止重新平衡。
-
当我们的kafka主题中有多个分区时，分区重新平衡是一件常见的事情吗？ 这并不一定意味着我们的应用程序存在延迟或问题？ 我一直看到分区被撤销和重新分配的日志。
-
我知道在你的流中的任何时间点都可能发生再平衡。当它发生时，由于没有提交给定偏移量的最新偏移量，可能会发生事件的重新处理。 Kafka流是否允许在重新平衡发生之前完成任何飞行中处理？我的意思是，你的应用程序正在消耗一个记录（在你的过程方法内部），发生一个再平衡事件。该处理是否立即中止或允许处理方法完成？ 一个具体的例子是 最后一次计算是否会在状态存储中结束并转发到接收器主题？因此，这意味着当重新平衡
-
一段时间后，Kubernetes controller将重新创建/重新启动失败/死亡的消费者实例，并再次执行新的重新平衡。 是否有任何方法来控制第一个重新平衡过程（当消费者死亡时）？例如，等待几秒钟而不重新平衡，直到失败的消费者返回，或者直到触发超时。如果消费者返回，是否继续基于旧的再平衡分配（即，没有新的再平衡）进行消费？
-
有人能告诉我Kafka消费者的再平衡算法是什么吗？我想了解分区计数和消费者线程是如何影响这一点的。 非常感谢。
-
我有4个单一分区和应用程序的三个实例的主题。我试图通过编写一个自定义的PartitionGrouper来实现可伸缩性，它将创建如下3个任务: 第一个实例-topic1，分区0，topic4，分区0 第二个实例-主题2，分区0 第三实例-桌面3，分区0 我将NUM_STANDBY_REPLICAS_CONFIG配置为1，因为它将在本地维护状态（也可以消除invalidstatestore异常）。 上
-
Kafka再平衡算法是否适用于不同主题？ 假设我有5个主题，每个主题都有10个分区，同一消费者组中有20个消费者应用程序实例，每个实例都订阅了这5个主题。 Kafka会尝试在20个实例中平衡50个分区吗？ 还是它只在一个主题内保持平衡，因此10个第一个实例可能（或可能）接收所有50个分区，而其他10个实例可能保持空闲？ 我知道，在过去，Kafka并没有在不同的主题之间取得平衡，但现在的版本呢？