技术学习分享_CKX技术 技术资讯 这个bug,你中招了吗?

这个bug,你中招了吗?

广告位

今天这篇文章,给大家分享一下最近看kafka源码时候,困扰我几天的疑惑,供大家一起思考讨论,确定一下它是不是一个 Bug 欢迎留言一起探讨!

这个 ” Bug ” ,发生在分区副本进行分配的时候, 为了让大家更好的理解,我把kafka里面所有情况的分区分配规则给大家详细讲解一下 「 不想看过程,可以直接看最后的总结部分 」

在kafka需要进行分区副本分配计算的地方有三个地方

  1. 「 Topic创建 」的时候
  2. 「 分区扩容 」的时候
  3. 「 分区副本重分配 」的时候

副本分配方式

副本分配的几个原则:

  1. 将副本平均分布在所有的 Broker 上;
  2. partition 的多个副本应该分配在不同的 Broker 上;
  3. 如果所有的 Broker 有机架信息的话, partition 的副本应该分配到不同的机架上。

这里我们为了描述简单,不分析有机架的情况

不管是什么时候的分配规则,最终调用的都是下面这个方法,为了分析分配情况,我加了一些日志

这个bug,你中招了吗?

通过这个分配方法我们可以得知,影响最终分配的方式有几个变量

  1. ​Broker List​​ 的顺序
  2. 起始随机分配BrokerID ​​startIndex​
  3. 第一个副本跟第二个副本的 起始间隔偏移量 ​​nextReplicaShift​

我们通过 创建Topic的情景来分析一下整体的分配规则;

创建Topic分区分配

Topic的创建可以看: [你知道Kafka创建Topic这个过程做了哪些事情吗?]

我们先看一个副本的分配情况

启动5个Broker, 创建一个Topic, 分区数10 副本数 1

单副本分配

这个bug,你中招了吗?

分配情况可以用如下图表示

这个bug,你中招了吗?

​起始随机索引是2​​, 也就是说起始BrokerId= Broker-4; 那么第一个副本P0-1(​​Leader​​)就从它开始分配了,后续的分配就是按照BrokerList就行遍历平均分配了,这样就让每个分区的​​Leader​​副本都均匀的分配到了不同的Broker上; 因为是单副本分配,​​newxtReplicaShit​​这个参数并没有用上;

多副本分配

启动5个Broker, 创建一个Topic, 分区数10 副本数 3;(还是跟上面一样,但是这个时候将副本数变成3个; 创建一个新的Topic = Test_Topic)

!](​​https://upload-images.jianshu.io/upload_images/28446384-2ac2077f81498710.png?imageMogr2/auto-orient/strip|imageView2/2/w/1240​​)

起始随机startIndex:2currentPartitionId:0;起始随机nextReplicaShift:4;brokerArray:ArrayBuffer(0, 1, 4, 2, 3)
(p-0,ArrayBuffer(4, 2, 3))
(p-1,ArrayBuffer(2, 3, 0))
(p-2,ArrayBuffer(3, 0, 1))
(p-3,ArrayBuffer(0, 1, 4))
(p-4,ArrayBuffer(1, 4, 2))
变更nextReplicaShift:5
(p-5,ArrayBuffer(4, 3, 0))
(p-6,ArrayBuffer(2, 0, 1))
(p-7,ArrayBuffer(3, 1, 4))
(p-8,ArrayBuffer(0, 4, 2))
(p-9,ArrayBuffer(1, 2, 3))
复制代码

这个得到的排列最终会写的zk中, 这些就是AR的值; 第一个为Leader

  1. ​Broker List​​ = {0,1,4,2,3}
  2. ​startIndes​​ = 2
  3. ​nextReplicaShift​​ = 4 这里跟 ​​nextReplicaShift​​ = 0 是一样的 (​​nextReplicaShift%(BrokerSize-1)​​)

这里跟单副本的时候基本上参数是一样, ​​nextReplicaShift​​ = 4 表示的是 第一副本和第二副本起始间隔4, 总共5个Broker,最终效果和起始0间隔是一样的,可以看下图,

这个bug,你中招了吗?

这个间隔的含义理解了,那我们看看这个整体的分配布局

这个bug,你中招了吗?

从这里我们不难看出:

​随机的startIndex​​ 可以尽量的让Leader不会分区堆积的情况,如果每次都是从0开始,那么每个Topic创建的时候第一个分区都落在0,假设分区不多,那么就会全部堆积到前面的Broker中,后面的Broker分配不到;

​nextReplicaShitf:​​ 尽量让单个Topic的副本分配的更散列一些

分区扩容分配方式

分区扩容的情况,也是调用上面的方法,分配规则都是一样的; 但是入参却又有一些不一样

不一样的地方,我把关键scala代码贴出来看看

这个bug,你中招了吗?

最终也是调用了​​AdminUtils.assignReplicasToBrokers​​方法; 但是入参有些不同

  1. ​Broker List​​ 是allBrokers; 这里allBrokers是从下面方法里获取的,从zk里面拿到Brokers节点再进行排序之后的列表; 如{0,1,2,3,4,5}
  2. 这个bug,你中招了吗?

  3. ​startIndex:​​ 在这里并不是一个随机值了,而是existingAssignmentPartition0.head获取的值; 这个表示的是当前Topic的第一个分区的第一个副本 在 Brokerlist中的索引值;
  4. ​nextReplicaShitf:​​ 这里跟startIndex是一个值; 如果入参指定了startIndexnextReplicaShitf:跟它一样,如下图代码
  5. 这个bug,你中招了吗?

  6. ​startPartitionId:​​ 这里的值是已经存在的分区数; 创建topic的时候这个值是0; [图片上传失败…(image-522218-1669001591923)]

那么那么把上面创建的t2(10分区,3副本), 执行一下分区扩容,扩容到13个;

这个bug,你中招了吗?

这个bug,你中招了吗?

这是扩分区后的情况, 因为这里刚好是 轮训两次再进行扩容的,可能看不出来问题,我们看另一个case

创建新Topic t5, 3个分区,1副本 如下

这个bug,你中招了吗?

扩分区到5个,新增的分区分配如下

这个bug,你中招了吗?

分配图

这个bug,你中招了吗?

如果要均衡分配的话,至少是 1、1、1、1、1 才算是均衡,现在是直接有一个Broker没有用上了;

为什么会出现这种情况?

我们先分析一下 写这段代码的人想做什么?

上图左边是最终扩容之后的分配,右边是扩容时候的计算方式; 从上我们可以分析得出

  1. 分区扩容不会变更之前的分配情况,只会变更重新计算扩容的那部分分区的分配规则;
  2. ​starIndex​​是第一分区的第一个副本在排序之后的BrokerList中的索引值; 然后按照分配规则进行分配,并且这个时候有​​startPartitionId​​ 截断前面的配置,只计算扩分区的这一部分;

从它这代码分析不就是想接着上一次继续分配吗?它把Broker List 排序了; 然后又是接着原来的计算方式进行分配 ①. ​​starIndex​​ 会让起始的分区副本相同, ok,这个变量相同了 ②. ​​nextReplicaShitf​​这个变量不会影响分区的Leader均衡,它的作用是尽量的离散一下副本

上面2个变量确定了,那么只要保证 第三个变量 ​​broker List​​的顺序,那么分配肯定就跟创建的时候一样(排除手动改掉的情况); 也就会总体分配均衡了; 那么实际情况 ​​broker List​​ 这个变量相同吗?

答案: 不相同!!!!!

创建的时候是 {0,1,4,2,3} 未经过排序 扩分区的时候 {0,1,2,3,4} 经过了排序

你要么就都排序,你要么就都接着用上一次的列表不好吗?

分析到这里, 我们已经肯定确定 分区扩容有可能会造成分区分区不均衡的情况 虽然这种影响很小,你我可能根本感知不出来,但是如果整个集群批量做扩容的时候, 会不会就扩大了这个问题的影响范围呢?

到这里我们可能不能确定说它是一个bug, 只是有一个怀疑的因子

但是如果创建Topic的时候就是有序的,那么这里就肯定不会出现扩容分区不均匀的情况啊!

那我们接着分析 分区副本重分配的方式

分区副本重分配方式

分区副本重分配的源码解析过程请看:[3万字长文呕心沥血教你彻底搞懂数据迁移原理(附配套教学视频)

这里就不再赘述了,直接抛出结果;

我们把上面扩容之后的topic = t5 来进行一下重分配,看看kafka会给我们推荐什么样子的分配方式;

这个bug,你中招了吗?

看图,我可以分析得出, brokerList = {0,1,2,3,4} ; 不管你执行几次 ​​--generate​​ 它的brokerList 都是{0,1,2,3,4} 有序的; 当然 ​​startIndex​​ 和 ​​nextReplicaShift​​ 都还是随机的;

至少重新分配之后, 分区是均衡的了

而且看源码, 是特意排序过的

凭什么只有创建Topic的时候不排序?

好,我思考思考,可能是有意为之,有一些其他的考量; 那么再贴出来创建Topic的时候Broker List的源码

这个bug,你中招了吗?

这个bug,你中招了吗?

再往上

这个bug,你中招了吗?

这个bug,你中招了吗?

这个bug,你中招了吗?

重点是在最后一张图 创建Topic拿到的Broker List 是Controller初始化的时候去zk里面获取的Broker节点;

  1. 先排序了!!!
  2. 然后通过这个BrokerID又去zk获取每个Broker的具体信息
  3. 返回结果最终 ​​toMap​​ 了放到Map对象去了,所以这也就是为什么不是有序的原因了;

这里排序不是有一点脱裤子放屁?多此一举的感觉吗

总结

那是不是bug呢? 我认为是的, 理由有以下几点

  1. 现有的情况,在扩分区的时候有可能会造成分区分配不均匀的情况
  2. 「 Topic创建 」的时候没有排序,可是「 扩分区」 、「 重分配 」 却又是排序了
  3. 「 Topic创建 」的时候没有排序,可是「 扩分区」的时候,它的计算逻辑是按照原有的分配方式就是顺序的
  4. 如果创建的时候是顺序的,那么「 扩分区」造成分配不均匀的情况就不会出现
  5. 「 Topic创建 」的时候,它先是排序了,可是最后却放到Map里面了,如果它不是最终想排序,为啥一开始的时候就排序?,因为这里的排序完全没有必要;
本文来自网络,不代表技术学习分享_CKX技术立场,转载请注明出处。

作者: CKX技术

上一篇
下一篇
广告位

发表回复

返回顶部