分区副本同步限流三部曲-实战篇
kafka管控推荐使用 滴滴开源 的 Kafka运维管控平台 更符合国人的操作习惯 ,
更强大的管控能力 ,更高效的问题定位能力 、更便捷的集群运维能力 、更专业的资源治理 、 更友好的运维生态
hello~ 大家好,我是石臻臻
今天这篇文章我们来讲一下分区副本同步限流机制三部曲中的 实战篇
问题描述
这个实战篇的case.是一个群友的问题, 具体情况如下。
这位同学发现zookeeper中的 动态配置 节点
/config/topics/Topic名称中的存在 节点数据1
2
3
4
5
6
7
8/** 下面的 ？ 是对应的值。 **/
{
"version": 1,
"config": {
"leader.replication.throttled.replicas": "?:?",
"follower.replication.throttled.replicas": "?:?"
}
}以前执行分区副本重分配的Josn文件找不到了。
问题分析
我们来分析一下这个问题, 这位同学的问题有以下几个点
- 这个配置是干啥的？
- 这个配置存在会对kafka集群会啥影响吗？
- 如何把这个配置给删除掉？
如果大家读过前面的 分区副本同步限流原理篇
那么肯定就能够自己去回答上面的几个问题了。
这个配置是用来干啥的
"leader.replication.throttled.replicas": Leader端的限流副本, 他的格式是分区号：BrokerID
"follower.replication.throttled.replicas": Follower端的限流副本,他的格式是分区号：BrokerID
这2个配置是在 执行 副本副本重分配的时候, 加了限流配置--throttle的时候, 会自动在zk中写入这两个配置。
这两个配置主要是记录 哪些分区需要在哪个Broker上需要进行Leader端的限流, 哪些分区需要在哪个Broker上进行Follower端的限流。
比如/config/topics/Topic1 新增了以下几个配置：
1 | { |
leader.replication.throttled.replicas
1：1: Topic1-1分区在Broker-1 上需要做Leader限流;1：0: Topic1-1分区在Broker-0 上需要做Leader限流0：0: Topic1-0分区在Broker-0 上需要做Leader限流;0：1: Topic1-0分区在Broker-1 上需要做Leader限流
"follower.replication.throttled.replicas"
1：2: Topic1-1分区在Broker-2 上需要做Follower限流0：2: Topic1-0分区在Broker-2 上需要做Follower限流
一句话：重分配后的新增的副本 均设置成 Follower副本限流, 重分配前的所有副本 均设置成Leader限流
这个配置存在会对kafka集群会啥影响吗
如果仅仅只有这两个配置的话, 那么不会对集群有啥影响。因为只设置了哪些副本需要限流,但是没有说限流多少, 默认是最大值,也就是
Long.MAXVALUE
但是, 一般情况下 有这个两个配置的话,一定会存在两位两个配置。
leader.replication.throttled.rate: 需要对Leader端 Fetcher返回的数据做限流,这里的配置就是限流的阈值
follower.replication.throttled.rate: 需要对Follower端去Leader 副本 Fetcher数据做限流,这里的配置就是限流的阈值
例如/config/brokers/0 /config/brokers/1 /config/brokers/2 这三个Broker都新增了属性：
1 | { |
可以看到, 里面配置的值都是通过--throttle 1048576设置的值 也就是说 1M/s.
只有这里面的配置还有上面 leader.replication.throttled.replicas、follower.replication.throttled.replicas 的配置一起才能达到限流的需求。
解决方法
一般情况下,我们执行完成 分区副本重分配的任务都会执行一下 -verify 。来验证一下是否真的完成了。
这个 --verify 不仅仅是验证这么简单, 当任务完成了, 这个命令会去把上面新增的限流相关的配置给移除掉。 不然的话就会有可能影响正常的副本同步的流量。
相关原理请看分区副本重分配源码原理分析(附配套教学视频)
存在原有的分区副本重分配的Json文件
只需要用原来的Json文件 执行一下 -verify
具体如何操作可以看 【kafka运维】kafka-reassign-partitions.sh分区副本重分配、数据迁移、副本扩缩容 (附教学视频)
不存在原有的分区副本重分配的Json文件
这种情况,就是今天这个文章的Case了，因为是很久之前的迁移任务, Json文件早就不存在了,以前做迁移的人也忘记了执行--verify. 那我们只能手动来进行移除掉。
这个也好办, 我们已经知道了限流相关的配置有哪些了, 只需要删除这些配置就行了。
而且这些配置是写在zookeeper中的动态配置。具体动态配置相关知识请看
删除动态配置
删除 所有Topic节点下的
leader.replication.throttled.replicas,follower.replication.throttled.replicas配置
这里需要注意,删除之前请确定当前没有分区重分配的操作,不然会把那个限流配置一起删除了。
有几个topic需要删除,则把--entity-name改成对应的topic进行删除。1
2
3
sh bin/kafka-configs.sh --bootstrap-server xxxxx:9092 --alter --entity-type topics --entity-name topic的名称 --delete-config leader.replication.throttled.replicas,follower.replication.throttled.replicas删除所有Broker配置节点的
leader.replication.throttled.replicas、follower.replication.throttled.replicas配置。
这里需要注意,删除之前请确定当前没有分区重分配的操作,不然会把那个限流配置一起删除了。
下面的命令,你有几台Broker需要删除，则需要把--entity-name改成对应的BrokerID 执行删除。1
2
3
sh bin/kafka-configs.sh --bootstrap-server xxxxx:9092 --alter --entity-type brokers --entity-name BrokerID啊 --delete-config leader.replication.throttled.replicas,follower.replication.throttled.replicas
问题扩展
上面的问题是解决了, 但是还遗漏了一种情况, 就是 跨目录同步的限流机制
跨目录同步限流解决方案
跨目录进行数据迁移的时候,限流机制跟上面还不一样,他有一个单独的配置。
哪个Broker需要限流, 则就会在zk的接口 /config/broker/brokdID 的配置中写入下面的属性。
replica.alter.log.dirs.io.max.bytes.per.second: 跨目录,同步限速。
只有这个配置，只需要把这个配置给删除就行了。
1 |
|
作者石臻臻,工作8年的互联网老兵,丰富的开发和管理经验,全网「 粉丝数4万 」,
先后从事 「 电商 」、「 中间件 」、「 大数据」 等工作
现在任职于「 滴滴技术专家 」岗位,从事开源建设工作
目前在维护 个人公众号「 石臻臻的杂货铺 」 ; 关注公众号会有「 日常送书活动 」;
欢迎进「 高质量 」 「 滴滴开源技术答疑群 」 , 群内每周技术专家轮流值班答疑
可帮忙「 内推 」一二线大厂
微信
石臻臻的杂货铺
Java/大数据/中间件/教学视频
