前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Kafka Consumer 的 Rebalance 机制

Kafka Consumer 的 Rebalance 机制

作者头像
haifeiWu
发布2020-02-10 17:50:34
2.4K0
发布2020-02-10 17:50:34
举报

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 信息,并将对应 PartitionOffset 信息记录到 Kafka 内置Topic(__consumer_offsets) 中。Kafka 在 0.9 之前是基于 Zookeeper 来存储 PartitionOffset 信息 (consumers/{group}/offsets/{topic}/{partition}),因为 Zookeeper 并不适用于频繁的写操作,所以在 0.9 之后通过内置 Topic 的方式来记录对应 PartitionOffset。如下图所示:

Kafka 0.8.2 之前是这样的

之后是这样的:

每个 Group 都会选择一个 Coordinator 来完成自己组内各 PartitionOffset 信息,选择的规则如下:

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

Partition计算规则:

代码语言:javascript
复制
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 期间可以继续运行

参考文章

作 者:haifeiWu 原文链接:https://www.hchstudio.cn/
本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • Kafka 之前版本的 Consumer Groups
    • Consumer Group
      • Group Coordinator
      • Consumer Rebalance Protocol
        • 发生 rebalance 的时机
          • 消费者进程挂掉的情况
          • 消费者的 Rebalance 协议
            • Rebalance 发生后的执行过程
              • Issues
              • 当前的 Rebalance 与 改进后的 ReBalance 对比
              • 渐进式 Rebalance 协议
              • 参考文章
              领券
              问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档