kakka rebalance解决方案

zz/2024/4/20 15:47:49

kakka rebalance解决方案

简介

    apache kafka的重平衡(rebalance),一直以来都为人诟病。因为重平衡过程会触发stop-the-world(STW),此时对应topic的资源都会处于不可用的状态。小规模的集群还好,如果是大规模的集群,比如几百个节点的consumer或kafka connect等,那么重平衡就是一场灾难。所以我们要尽可能避免重平衡。在kafka2.4的时候,社区推出两个新feature来解决重平衡过程中STW的问题。
1. Incremental Rebalance Protocol(以下简称cooperative协议):改进了eager协议(即旧重平衡协议)的问题,避免STW的发生,具体怎么避免,后面介绍
2. static membership:避免重起或暂时离开的消费者触发重平衡

apache kafak2.4 incremental cooperative rebalancing协议

背景

      负载均衡,基本是分布式系统中必不可少一个功能,apache kafka也不例外。为了让消费数据这个过程在kafka集群中尽可能地均衡,kafka推出了重平衡的功能,重平衡能够帮助kafka客户端(consumer client,kafkaconnect,kafka stream)尽可能实现负载均衡。但是在kafka2.3之前,重平衡各种分配策略基本都是基于eager协议的(包括RangeAssignor,RoundRobinAssignor等),也就是我们以前熟知的kafka重平衡 值得一提的是,此前kafka就有推出一个重平衡的新分配策略,`StickyAssignor`粘性分配策略,主要作用是保证客户端,比如consumer消费者在重平衡后能够维持原本的分配方案,可惜的是这个分配策略依旧是在eager协议的框架之下,重平衡仍然需要每个consumer都先放弃当前持有的资源(分区)。 在2.x的时候,社区就意识到需要对现有的rebalance作出改变。所以在kafka2.3版本首先在kafka connect应用cooperative协议,然后在kafka2.4的时候也在consumer client添加了该协议的支持。 

incremental cooperative rebalancing协议解析

接下来我们介绍cooperative协议和eager协议的具体区别。一句话介绍,**cooperative协议将一次全局重平衡,改成每次小规模重平衡,直至最终收敛平衡的过程**。这里我们主要针对一种场景举个例子,来对比两种协议的区别。假设有这样一种场景,一个topic有三个分区,分别是p1,p2,p3。有两个消费者c1,c2在消费这三个分区,{c1 -> p1, p2},{c2 -> p3}。当然这样说不平衡的,所以加入一个消费者c3,此时触发重平衡。我们先列出在eager协议的框架下会执行的大致步骤,然后再列出cooperative发生的步骤,以做比对。

eager 协议版本各个名词:

- group coordinator:重平衡协调器,负责处理重平衡生命周期中的各种事件- hearbeat:consumer和broker的心跳,重平衡时会通过这个心跳通知信息- join group request:consumer客户端加入组的请求- sync group request:重平衡后期,group coordinator向consumer客户端发送的分配方案如果在 eager 版本中,会发生如下事情。1. 最开始的时候,c1 c2 各自发送hearbeat心跳信息给到group coordinator(负责重平衡的协调器)2. 这时候group coordinator收到一个join group的request请求,group coordinator知道有新成员加入组了3. 在下一个心跳中group coordinator 通知 c1 和 c2 ,准备rebalance4. **c1 和 c2 放弃(revoke)各自的partition**,然后发送joingroup的request给group coordinator5. group coordinator处理好分配方案(交给leader consumer分配的),发送sync group request给 c1 c2 c3,附带新的分配方案6. c1 c2 c3接收到分配方案后,重新开始消费

用一张图表示如下:
在这里插入图片描述

这里省略了一些细节,不过整体上应该会更方便理解这个过程。接下来再看看cooperative协议会怎么处理。

到了cooperative协议就会变成这样:

cooperative rebalancing protocol

如果在cooperative版本中,会发生如下事情。1. 最开始的时候c1 c2各自发送hearbeat心跳信息给到group coordinator2. 这时候group coordinator收到一个join group的request请求,group coordinator知道有新成员加入组了3. 在下一个心跳中 group coordinator 通知 c1 和 c2 ,准备 rebalance,前面几部分是一样的4. **c1 和 c2发送joingroup的request给group coordinator,但不需要revoke其所拥有的partition,而是将其拥有的分区编码后一并发送给group coordinator,即 {c1->p1, p2},{c2->p3}**5. group coordinator 从元数据中获取当前的分区信息(这个称为assigned-partitions),再从c1 c2 的joingroup request中获取分配的分区(这个称为 owned-partitions),通过assigned-partitions和owned-partitions知晓当前分配情况,决定取消c1一个分区p2的消费权,然后发送sync group request({c1->p1},{c2->p3})给c1 c2,让它们继续消费p1 p26. c1 c2 接收到分配方案后,重新开始消费,一次 rebalance 完成,**当然这时候p2处于无人消费状态**7. 再次触发rebalance,重复上述流程,不过这次的目的是把p2分配给c3(通过assigned-partitions和owned-partitions获取分区分配状态)

同样用一张图表示如下:
在这里插入图片描述

cooperative协议版重平衡的一个核心,是assigned-partitions和owned-partitions,group coordinator通过这两者,可以保存和获取分区的消费状态,以便进行多次重平衡并达到最终的均衡状态。除了消费者崩溃离场的场景,其他场景也是类似的思路

apache kafka2.4 static membership功能

我们知道,当前重平衡发生的条件有三个:- 成员数量发生变化,即有新成员加入或现有成员离组(包括主动离组和崩溃被动离组)
- 订阅主题数量发生变化
- 订阅主题分区数量发生变化其中成员加入或成员离组是最常见的触发重平衡的情况。新成员加入这个场景必然发生重平衡,没办法优化(针对初始化多个消费者的情况有其他优化,即延迟进行重平衡),但消费者崩溃离组却可以优化。因为一个消费者崩溃离组通常不会影响到其他{partition - consumer}的分配情况。
**因此在 kafka 2.3~2.4 推出一项优化,即此次介绍的[Static Membership](https://www.lmlphp.com/r?x=CtQ9ytoWsjbvPE4vPHw7yekGCeT6zihAs_gMsMQVPiKd4Ew9PLQ3zMlVgiI9PLQ3PSbd4ESN4Lh_CerO5tOwp8)功能和一个consumer端的配置参数 `group.instance.id`**。一旦配置了该参数,成员将自动成为静态成员,否则的话和以前一样依然被视为是动态成员。**静态成员的好处在于,其静态成员ID值是不变的,因此之前分配给该成员的所有分区也是不变的。即假设一个成员挂掉,在没有超时前静态成员重启回来是不会触发 Rebalance 的**(超时时间为`session.timeout.ms`,默认10 sec)。在静态成员挂掉这段时间,broker会一直为该消费者保存状态(offset),直到超时或静态成员重新连接。如果使用了 static membership 功能后,触发 rebalance 的条件如下:- 新成员加入组:这个条件依然不变。当有新成员加入时肯定会触发 Rebalance 重新分配分区
- Leader 成员重新加入组:比如主题分配方案发生变更
- 现有成员离组时间超过了 `session.timeout.ms` 超时时间:即使它是静态成员,Coordinator 也不会无限期地等待它。一旦超过了 session 超时时间依然会触发 Rebalance
- Coordinator 接收到 LeaveGroup 请求:成员主动通知 Coordinator 永久离组。
所以使用static membership的两个条件是:1. consumer客户端添加配置:props.put("group.instance.id", "con1");
2. 设置`session.timeout.ms`为一个合理的时间,这个参数受限于`group.min.session.timeout.ms`(6 sec)和`group.max.session.timeout.ms`(30 min),即大小不能超过这个上下限。但是调的过大也可能造成broker不断等待挂掉的消费者客户端的情况,个人建议根据使用场景,设置合理的参数。以上~

http://www.ngui.cc/zz/2389899.html

相关文章

oracle rebalance参数,理解ASM(四)条带化原理和rebalance

㈠ 条带化ASM的条带化有两种:coarse和fine-gainedAU是最小空间分配单元,缺省是1M,每个AU缺省由8个128K条带空间组成。在coarse条带化中,一个磁盘对应一个AU所以该条带化适合连续的I/O读写,比如全表扫描表在fine-gained…

kafka consumer、partition、rebalance

发送消息分配partition Producer发送消息到Topic时,分配partition的算法如下: 如果指定了一个partition,那么直接使用指定的partition 如果没有指定partition,但是指定了key,那么会根据key进行哈希,分配到…

oracle12.2 asm进程,Oracle ASM Rebalance执行过程

磁盘组的rebalance什么时候能完成?这没有一个具体的数值,但ASM本身已经给你提供了一个估算值(GV$ASM_OPERATION.EST_MINUTES),想知道rebalance完成的精确的时间,虽然不能给出一个精确的时间,但是可以查看一些rebalance…

10.Kafka ---- 重新负载Rebalance过程

1.什么是Rebalance重新负载? Rebalance,即对 Kafka 中的分区进行重新分配的过程。如需详细了解 Kafka 的分区分配策略,请点击链接跳转了解更多:8.Kafka 分区分配策略 2.什么时候触发Rebalance操作 当出现以下几种情况时&#xff…

asm rebalance 三个阶段

The disk group rebalance operation has three phases: Planning -一般30秒内File extents relocation --add 3块2t盘- 1T数据 2小时 drop 1T 1.5小时 add 10块2t盘- 8T数据 8小时 drop 5T 8小时Disk compacting --drop 3块2t盘-1T 40分钟 ,add 8T 4小时GOAL Wha…

rebalance的使用

上篇:project的使用 rebalance the output elements are distributed evenly to instances of the next operation in a round-robin fashion 按照round-robin的方式,决定上游算子的某个并发的数据发往下游的哪个并发。该方法可以保证从上游算子到下游…

Kafka rebalance 重平衡深度解析

文章目录rebalance 触发条件分区分配策略rebalance generation消费者状态机rebalance 协议消费者端 rebalance 流程Broker 端重平衡场景解析新成员入组组成员主动离场组成员崩溃离场重平衡时协调者对组内成员提交位移的处理rebalance 监听器consumer group 是用于实现高伸缩性、…

kafka消费者Rebalance机制

目录 1、Rebalance机制 2、消费者Rebalance分区分配策略 3、Rebalance过程 1、Rebalance机制 rebalance就是说如果消费组里的消费者数量有变化或消费的分区数有变化,kafka会重新分配消费者消费分区的关系。比如consumer group中某个消费者挂了,此时会…

RocketMQ源码(十九)之消费者Rebalance

文章目录版本简介Broker端ConsumerManagerConsumerOffsetManagerSubscriptionGroupManager消费端RebalanceService分配策略版本 基于rocketmq-all-4.3.1版本 简介 集群消息同一个消费组只能有一个消费者消费,如果一个Topic有4个MessageQueue,对于Consu…

oracle rebalance参数,【案例】Oracle ASM扩展新LAN加入asm diskgroup asm rebalance 原理

天萃荷净Oracle研究中心案例分析:运维DBA反映Oracle数据库的ASM空间不足,需要扩展。通过划新的LAN加入asm diskgroup并分析asm rebalance 原理。本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger 的O…