Coding fly的博客

最近有朋友在问我关于消费组rebalance的问题的时候有提到过引起rebalance的原因，其中一条就是partition leader切换会引起消费组的rebalance，一般来说大家经常提的原因有以下三个1、成员数量发生变化，有成员加入组或者退组2、订阅的topic发生变化3、订阅的topicPartition发生变化我也是第一次见人说partition leader切换会引起消费者Rebalance，于是从这个角度来分析一下是不是真的会发生......

本文以kafka源码2.8为例，启用源码。

图解kafka消费者加入组流程

这部分主要来说明消费者对协议的处理。各个消费者都可设置partition.assignment.strategy(分区分配策略)，服务端是如何处理的呢？这块的代码要追溯到joinGroup请求结束，通过前面的源码分析我们知道joinGroup主要是判断是否发起rebalance以及等待其他组成员加入组，而在所有成员加入或者RebalanceTimeout之后会调用onCompleteJoin方法，代码如下。def onCompleteJoin(group: GroupMetadata): Unit

主要是kafka消费者的joinGroup这里的重点内容太多了，一篇也讲不完，所以再开一篇从几个方面来深入分析。group状态转换从上一篇我们知道针对consumeGroup也有好几种状态，分别是PreparingRebalance，CompletingRebalance，Stable，Dead，Emptykafka总结的各个状态可以执行的操作及状态流转如图一PreparingRebalance：准备重平衡心跳检测同步group信息收到leaveGroupRequest等待group成员

这一节我们主要来分析joinGroup这块的代码，主要流程如图一。流程展示拆解JoinGroup协议客户端的代码我们就不拿出来说了，等后面说到关键点的时候再拿出来一起分析，这里目前只需要知道会发JoinGroupRequest请求给服务端，请求及返回数据样例如下，协议的结构见图二及图三。JoinGroupRequestData(groupId=‘mykafka-group’, sessionTimeoutMs=10000, rebalanceTimeoutMs=300000,memberId=

在这里我们先来梳理一下consumeGroup的相关知识1、首先，我们会给每个consume设置groupId，对于相同groupId且订阅相同topic的consume，会组成consumeGroup，如图一所示2、对于Server端的topic来说，会有partition这个概念，如图二所示3、现在我们有多个consume及多个partition，到底由哪个consume来消费哪个partition呢？就由consume启动时的分区分配策略来决定。如果consume数量小于partiti

消费端参数配置| ---- | ----------------------------- | ---------------- | ---- | ------------------------------------------------------------ || 1 | bootstrap.servers | | 高 | 指定连接kafka集群所需的broker地址清单 ||

前言：今天我们来分析一下怎么修改分区指定的副本为leader分析分区重分配可以实现这个功能吗？不了解分区重分配的流程可以先学习前面关于分区重分配的知识，这里我们只是带着疑问再次回顾分区重分配的代码。分区重分配关键代码展示kafka.controller.KafkaController#updateCurrentReassignment此方法的作用就是将分区重分配数据写入zk及controllerContext，这里要对controllerContext的作用特别说明一下，首先从语义上就能猜到这个类

分区leader选举脚本执行介绍脚本参数配置kafka触发副本选举的脚本是bin/kafka-leader-election.sh配置参数为：序号参数说明1bootstrap-serverkafka集群地址清单2admin.config指定客户端config配置文件3path-to-json-file指定选举副本JSON文件4topicpath-to-json-file或all-topic-partitions或指定topic5part

在分析之前我们先回顾一下哪些场景会发送StopReplicaRequest副本转换为OfflineReplica状态private def doHandleStateChanges(replicaId: Int, replicas: Seq[PartitionAndReplica], targetState: ReplicaState): Unit = { targetState match { case OfflineReplica => //对有效的副本

此文章基于kafka2.5kafka状态机有两种，一种是ReplicaStateMachine副本状态机，另一种是PartitionStateMachine分区状态机，下面我们就来分别介绍一下状态机启动的入口kafka.controller.KafkaController#onControllerFailover在服务端controller选举之后会启动状态机private def onControllerFailover(): Unit = { //……省略 replicaSt.

此文章基于kafka2.5，协议版本为11为了能更加了解上一篇中的18b流量怎么来的，这里我们来深入分析一下首先来看FetchRequest的结构FetchResponse的结构18b流量的来源想要了解18b流量就需要深入了解kafka.server.KafkaApis#sizeOfThrottledPartitions方法，代码如下 private def sizeOfThrottledPartitions(versionId: Short, .

这一篇我们主要来看看分区副本重分配限流是如何实现的，此源码分析基于kafka2.5版本。在开始之前我们先来回顾一下分区重分配的流程，如图一所示。[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传执行分区重分配脚本，这里相当于起了个kafka客户端，执行完脚本将重分配数据写入zk即返回了。kafkaController监听到zk分区重分配节点数据变动，会调相应的handler来处理数据，这里相当于kafka服务端大脑的角色，控制了分区重分配主要处理的流程，并发送命令给其他节点执行，描

kafka分区副本重分配的脚本是kafka-reassign-partitions.sh配置参数为：序号参数说明1bootstrap-serverkafka集群地址清单2command-config3zookeeperzk集群地址4generate生成分区副本重分配策略5execute按照策略json执行分区副本重分配6verify验证迁移任务是否成功7reassignment-json-file指定重分配策略文件