↓ 跳过正文
haifeiWu
haifeiWu
  1. 文章/

Kafka Consumer 的 Rebalance 机制

3 分钟· ·
后端 Java Kafka
haifeiWu
作者
haifeiWu
北京后端开发者，热爱分布式系统、中间件与 AI 工程，正在深入学习 Go 与 Rust。
目录

📌 本文原发布于掘金社区：Kafka Consumer 的 Rebalance 机制

Kafka Consumer 的 Rebalance 机制-原文链接
Kafka Consumer 的 Rebalance 机制-原文链接
Kafka Consumer 的 Rebalance 机制-原文链接\

上周参加了 Kafka Meetup 北京站的技术分享，本文简单介绍下 Kafka Consumer 的 Rebalance 机制以及其新版本中的优化策略~

Kafka 之前版本的 Consumer Groups
#

Consumer Group
#

如上图所示，Consumer 使用 Consumer Group 名称标记自己，并且发布到主题的每条记录都会传递到每个订阅消费者组中的一个 Consumer 实例。Consumer 实例可以在单独的进程中或在单独的机器上。

如果所有 Consumer 实例都属于同一个 Consumer Group，那么这些 Consumer 实例将以负载均衡的方式来消费 Kafka。

如果所有 Consumer 实例具有不同的 Consumer Group，则每条记录将被广播到所有 Consumer 进程。

Group Coordinator
#

Group Coordinator 是一个服务，每个 Broker在启动的时候都会启动该服务。Group Coordinator 的作用是存储 Group 的相关 Meta 信息，并将对应 Partition 的 Offset 信息记录到 Kafka 内置Topic(__consumer_offsets) 中。Kafka 在 0.9 之前是基于 Zookeeper 来存储 Partition 的 Offset 信息 (consumers/{group}/offsets/{topic}/{partition})，因为 Zookeeper 并不适用于频繁的写操作，所以在 0.9 之后通过内置 Topic 的方式来记录对应 Partition 的 Offset。如下图所示：

在 Kafka 0.8.2 之前是这样的

之后是这样的：

每个 Group 都会选择一个 Coordinator 来记录自己组内各 Partition 的 Offset 信息，选择的规则如下：

  1. 计算 Group 对应在 __consumer_offsets 上的 Partition
  2. 根据对应的 Partition 寻找该 Partition 的 leader 所对应的 Broker，该 Broker 上的 Group Coordinator 就是该 Group 的 Coordinator

Partition 计算规则：

partition-Id(__consumer_offsets) = Math.abs(groupId.hashCode() % groupMetadataTopicPartitionCount)

其中 groupMetadataTopicPartitionCount 对应 offsets.topic.num.partitions 参数值，默认值是 50 个分区

Consumer Rebalance Protocol
#

发生 rebalance 的时机
#

  1. 组成员个数发生变化。例如有新的 consumer 实例加入该消费组或者离开组。
  2. 订阅的 Topic 个数发生变化。
  3. 订阅 Topic 的分区数发生变化。

消费者进程挂掉的情况
#

  1. session 过期
  2. heartbeat 过期

Rebalance 发生时，Group 下所有 Consumer 实例都会共同参与，Kafka 能够保证尽量达到最公平的分配。但是 Rebalance 过程对 Consumer Group 会造成比较严重的影响。在 Rebalance 的过程中 Consumer Group 下的所有消费者实例都会停止工作，等待 Rebalance 过程完成。

消费者的 Rebalance 协议
#

Rebalance 发生后的执行过程
#

1，有新的 Consumer 加入 Consumer Group

2，从 Consumer Group 选出 leader

3，leader 进行分区的分配

Issues
#

Known Issue #1: Stop-the-world Rebalance

如上图所示：之前版本的 Kafka 在发生 Rebalance 的时候会释放 Consumer Group 的所有资源，造成比较长的 Stop-the-world

Known Issue #2: Back-and-forth Rebalance

如上图所示：在发生 Rebalance 的时候发生了不必要的资源释放与重新分配。

当前的 Rebalance 与 改进后的 ReBalance 对比
#

渐进式 Rebalance 协议
#

如上图所示，新的渐进式 Rebalance 协议，在 Rebalance 的时候不需要当前所有的 Consumer 释放所拥有的资源，而是当需要触发 Rebalance 的时候对当前资源进行登记，然后进行渐进式的 Rebalance。这样做产生的优化效果如下

  • 相较之前进行了更多次数的 Rebalance，但是每次 Rebalance 对资源的消耗都是比较廉价的
  • 发生迁移的分区相较之前更少了
  • Consumer 在 Rebalance 期间可以继续运行

参考文章
#

关注我们
#

关注我们

相关文章