【kafka实践】10|消费者重平衡

消费者组这一章节中提到过重平衡Rebalance,Rebalance 就是让 Consumer Group 下所有的 Consumer 实例就如何消费订阅主题的所有分区达成共识的过程。在 Rebalance 整个过程中,所有实例都不能消费任何消息,因此它对 Consumer 的 TPS 影响很大。

在整个重平衡过程中,是在协调者 Coordinator 得参与下完成的,它专门为 Consumer Group 服务,负责执行 Rebalance 以及提供位移管理和组成员管理等。

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

所有 Broker 在启动时,都会创建和开启相应的 Coordinator 组件。Consumer Group 如何确定为它服务的 Coordinator 在哪台 Broker 上呢?其实就是通过我们上一节提到的内部位移主题 __consumer_offsets。

确定 Coordinator 所在的 Broker 有 2 个步骤:

  1. 确定位移主题在哪个分区partitionId=Math.abs(groupId.hashCode() % offsetsTopicPartitionCount)。
  2. 找出该分区 Leader 副本所在的 Broker,即为对应的 Coordinator。

实际使用过程中,Consumer 能够自动发现并连接正确的 Coordinator。这个算法能够帮助我快速定位问题。当 Consumer Group 出现问题,需要快速排查 Broker 端日志时,我们能够根据这个算法准确定位 Coordinator 对应的 Broker,不必一台一台查。

我们提到Rebalance会影响性能,其实主要从三个点:

  1. Rebalance 影响 Consumer 端 TPS
  2. Rebalance 消费者组成员越多越慢
  3. Rebalance 效率不高,每次平衡全员参与

前面章节提到Rebalance 的触发条件有 3 个:

  1. 组成员数发生变更。Consumer 实例down机,或是增加 Consumer 实例。
  2. 订阅主题数发生变更。Consumer Group 可以使用正则表达式的方式订阅主题,比如 consumer.subscribe(Pattern.compile("toppic.*")) 就表明该 Group 订阅所有以toppic开头的主题。你新创建了topic_new。
  3. 订阅主题的分区数发生变更。Kafka 当前只能允许增加一个主题的分区数。

其实在大多数情况下我们应该尽量去避免重平衡的发生,但是重平衡的本质还是为了按照规则均匀分配分区进行消费,2、3情况都是人为变更,可以在前期设计上尽量规划避免。关于down机这种情况,其实可以分为真down,和 Coordinator 以为你down了,那么我们能更多能控制的应该是"Coordinator 以为你down了"。

每个 Consumer 实例都会向 Coordinator 发送心跳,表明它还存活着。如果某个 Consumer 实例不能及时地发送这些心跳请求,Coordinator 就会认为该 Consumer 已经 down 了,从开启新的 Rebalance。Consumer 端有个参数,叫 session.timeout.ms,默认值是 10 秒,即如果 Coordinator 在 10 秒之内没有收到 Group 下某 Consumer 实例的心跳,它就会认为这个 Consumer 实例已经 down 了,session.timeout.ms 决定了 Consumer 存活性的时间间隔。

还有这个参数heartbeat.interval.ms,控制心跳频率,值越小,频率就越高。频繁地发送心跳请求会额外消耗带宽资源,但好处是能够更加快速地知晓当前是否开启 Rebalance,目前 Coordinator 通知各个 Consumer 实例开启 Rebalance 的方法,就是将 REBALANCE_NEEDED 标志封装进心跳请求的响应体中。

如果能及时发出心跳,就能避免由于心跳引起的 Rebalance,这里给出一些经验值:

  1. session.timeout.ms = 6s
  2. heartbeat.interval.ms = 2s。
  3. 保证 session.timeout.ms >= 3 * heartbeat.interval.ms

当然在实际的生产场景中还需要根据运行情况,酌情处理,如果有频繁的 Rebalance 可能还需要检查网络,内存,或是消费者端消费情况等。大家有什么重平衡的理解与心得欢迎评论区分享讨论

相关推荐
2501_941142131 小时前
前端高性能优化与微前端架构设计在大型互联网系统中的实践经验分享
kafka
20岁30年经验的码农2 小时前
Kafka 消息中间件实战指南
分布式·kafka·linq
无心水2 小时前
【分布式利器:限流】4、异步场景限流:消息队列削峰填谷+动态限流实现
分布式·mq·分布式限流·动态限流·分布式利器·异步场景限流·消息队列削峰填谷
z***89713 小时前
【分布式】Hadoop完全分布式的搭建(零基础)
大数据·hadoop·分布式
隐语SecretFlow4 小时前
【隐语Serectflow】基于隐私保护的分布式数字身份认证技术研究及实践探索
分布式
回家路上绕了弯4 小时前
支付请求幂等性设计:从原理到落地,杜绝重复扣款
分布式·后端
小马爱打代码5 小时前
SpringBoot + Quartz + Redis:分布式任务调度系统 - 从架构设计到企业级落地
spring boot·redis·分布式
yumgpkpm7 小时前
腾讯云TBDS与CDH迁移常见问题有哪些?建议由CDH迁移到CMP 7.13 平台(类Cloudera CDP,如华为鲲鹏 ARM 版)
hive·hadoop·zookeeper·flink·spark·kafka·hbase
无心水8 小时前
【分布式利器:限流】3、微服务分布式限流:Sentinel集群限流+Resilience4j使用教程
分布式·微服务·架构·sentinel·分布式限流·resilience4j·分布式利器
一起学开源9 小时前
分布式基石:CAP定理与ACID的取舍艺术
分布式·微服务·架构·流程图·软件工程