重平衡

Rebalance 就是让一个 Consumer Group 下所有的 Consumer 实例就如 何消费订阅主题的所有分区达成共识的过程。在 Rebalance 过程中，所有 Consumer 实例 共同参与，在协调者组件的帮助下，完成订阅主题分区的分配。但是，在整个过程中，所有 实例都不能消费任何消息，因此它对 Consumer 的 TPS 影响很大。

所谓协调者，在 Kafka 中 对应的术语是 Coordinator，它专门为 Consumer Group 服务，负责为 Group 执行 Rebalance 以及提供位移管理和组成员管理等。

具体来讲，Consumer 端应用程序在提交位移时，其实是向 Coordinator 所在的 Broker 提交位移。同样地，当 Consumer 应用启动时，也是向 Coordinator 所在的 Broker 发送 各种请求，然后由 Coordinator 负责执行消费者组的注册、成员管理记录等元数据管理操 作。

所有 Broker 在启动时，都会创建和开启相应的 Coordinator 组件。也就是说，所有 Broker 都有各自的 Coordinator 组件。那么，Consumer Group 如何确定为它服务的 Coordinator 在哪台 Broker 上呢？答案就在我们之前说过的 Kafka 内部位移主题 __consumer_offsets 身上。

目前，Kafka 为某个 Consumer Group 确定 Coordinator 所在的 Broker 的算法有 2 个 步骤。

第 1 步：确定由位移主题的哪个分区来保存该 Group 数据： partitionId=Math.abs(groupId.hashCode() % offsetsTopicPartitionCount)。

第 2 步：找出该分区 Leader 副本所在的 Broker，该 Broker 即为对应的 Coordinator。

重平衡的弊端

  • 影响Consumer端TPS
  • 重平衡很慢
  • 效率不高。

重平衡的发生时机

  • 组成员数量发生变化
  • 订阅主题数量发生变化
  • 订阅主题的分区数发生变化