13 张图让你学会 Kafka 分区副本同步限流机制

ImportNew

今天我们来讲解一下限流机制。本文提到的限流机制指副本之间的同步限流机制，并不包含生产者、消费组等其他限流。

那么讲到副本同步，大家都知道，正常情况下我们是不会给副本的同步加上限流值的。因为这样子很可能会导致副本跟不上 ISR（in-sync replica），那么什么情况下我们需要加上这个限流值呢？

分区副本重分配的场景下，我们可能担心大批量的数据进行迁移会占用过多的资源，导致 Kafka 集群压力增大进而影响正常使用。所以，一般情况下我们可能会选择在低峰期进行操作，也会对整个操作做一个限流处理。

设置限流的时候有两个参数选项，可以同时配置：

--replica-alter-log-dirs-throttle：broker 内部副本跨路径迁移数据流量限制功能，限制数据拷贝从一个目录到另外一个目录带宽上限，单位 bytes/sec；
--throttle：迁移过程中 Broker 之间传输的速率，单位 bytes/sec。

那么你会不会发出这样的疑问：

--throttle：迁移过程 Broker 之间传输的速率，这里的“Broker 之间”是谁和谁之间？
Broker之间传输的速率怎么算？是 Broker 整体所有分区副本的传输速率，还是指定几个分区副本的传输速率？
这个传输速率是什么？是 Broker 数据流出的速率，还是数据流入的速率，还是网卡的速率？
--replica-alter-log-dirs-throttle 又是怎么限制住 Broker 不同目录直接的流量的？
如何正确设置这些限流值呢？有哪些参考标准？
可以手动设置限流吗？

假如你有这些疑问并稍作思考之后，请跟着我下面的讲解来重新梳理一下吧。

1. 不同 Broker 之间副本同步限流

对于这个问题我写一个例子，通过示例就很容易明白。现在有 3 个 Broker，一个 Topic：

分区副本重分配

在执行以下脚本进行分区重分配之后：


sh bin/kafka-reassign-partitions.sh  --zookeeper xxxx:2181/src1 --reassignment-json-file config/reassignment-json-file.json --execute --bootstrap-server xxxxxx:9090 --throttle 1048576

可以看到 ZooKeeper 配置中新增了以下几个属性：

Broker节点配置

/config/brokers/0/config/brokers/1/config/brokers/2 这三个Broker都新增了属性


{   "version": 1,   "config": {      "leader.replication.throttled.rate": "1048576",      "follower.replication.throttled.rate": "1048576"   }}

leader.replication.throttled.rate：需要对 Leader 端 Fetcher 返回的数据做限流。这里的配置就是限流的阈值；
follower.replication.throttled.rate：需要对 Follower 端去 Leader 副本 Fetcher 数据做限流。这里的配置就是限流的阈值。

可以看到，里面配置的值都是刚刚通过 --throttle 1048576 设置的 1M/s。

这里配置了这两个属性的意思是：3 个 Broker 既要做 Leader 端限流，又要做 Follower 端限流，并且限流的阈值都是 1M/s。

当然，这里配置了限流阈值就完了吗？

是需要所有的数据流入流出都要限流？还是只是部分分区限流？

Topic 节点配置

/config/topics/Topic1 新增了以下几个配置：


{   "version": 1,   "config": {      "leader.replication.throttled.replicas": "1:1,1:0,0:0,0:1",      "follower.replication.throttled.replicas": "1:2,0:2"   }}

leader.replication.throttled.replicas：Leader 端的限流副本，它的格式是分区号：BrokerID。上面配置含义如下：

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 限流。

从这里可以看到，基本上原始分区副本都需要配置 Leader 端进行限流。并且是所有涉及到的 Broker。

为什么呢？因为在副本分配过程中，以前的所有副本都有可能成为 Leader。比如之前 Broker-0 里面的 Topic1-0 是 Leader 副本。

如果 Broker-0 不小心宕机了，那么 Leader 就变成了 Broker-1 中的副本。所以，需要把之前的所有副本都要设置 Leader 限流。

follower.replication.throttled.replicas：Follower 端的限流副本，它的格式是分区号: BrokerID。上面配置含义如下：

1:2 - Topic1-1 分区在 Broker-2 上需要做 Follower 限流；
0:2 - Topic1-0 分区在 Broker-2 上需要做 Follower 限流。

这里更简单一点，相当于是新增的副本和对应的 Broker 都做 Follower 限流。

一句话总结：重分配后的新增的副本均设置成 Follower 副本限流，重分配前的所有副本均设置成 Leader 限流。

2. 看看 Leader 限流和 Follower 整体限流图

分区副本重分配限流图

看完这个图，可以思考下面的问题：

如果这个上面的每个分区副本大小都是 100M, 那么上面的配置（限流 1M/s）最终执行完成同步，需要多长的时间呢？

站在 Leader 的角度看限流

Broker-0 中只有 Topic1-0 一个 Leader 需要进行同步（数据流出）并且只有一个 Broker-2 上的副本需要同步（同步①）。那么完成同步的时间 = 100M / Leader端的限流1M/S = 100秒。意思是最少需要 100 秒。

同理 Broker-1 也是最少需要 100 秒。

站在 Follower 的角度看限流

Broker-2 因为有 2 个副本同时在同步, 那么总共需要 Fetch 的数据量是 100*2 = 200M

然后又因为Follower限流是 1M/S 所以完成同步的时间最少需要 200/1 = 200s。

也就是说还没有等到 Broker-0 和 Broker-1 达到它的限流值之前，Broker-2 就已经被限流了。

所以，最终的时间是 200秒。

所以跟你想到的答案一致吗？

3. 各种条件下的限流情况

1) Leader 限流，Follower 不限流

结论：

Leader 端的限流只会计算需要被限流的分区流量值；
如果多个副本向 Leader 端 Fetch 数据，那么都会被算进限流阈值。基本上多一个副本就多一倍的时间。

如果有多个 Leader 分区都限流呢？

按照最终有多少个副本在 Fetch 数据。

2) Leader 不限流，Follower 限流

对应的配置有 follower.replication.throttled.replicas ：Follower 分区副本的限流配置 follower.replication.throttled.rate Follower 分区副本限流阈值 b/s。

3) Topic1 单分区 2 副本和 Topic1 双分区 2 副本

4) Topic1 多分区、多副本

多个分区、多个副本在不同的 Broker 上, 不同的 Broker 的流量只会算在单台 Broker。

上图中的两个 Leader 都是 100M。

最终决定完成重分配任务关键点是什么？

那就是 Leader 端和 Follower 端的限流哪个先达到阈值。

a) Leader 端先达到阈值

b) Follower 先达到阈值

5) 同 Broker 跨目录同步限流

这个指的是一个 Broker 可能有多个目录，我们可能会针对不同目录做一些数据迁移。当然，这个过程也会限流。

这个就是跨目录数据迁移。在执行这个操作的时候，设置限流 1M/s --replica-alter-log-dirs-throttle 1048576。

那么，会在 Broker 配置节点新增如下配置 /config/broker/0：

{   "version": 1,   "config": {      "replica.alter.log.dirs.io.max.bytes.per.second": "1048576"   }}

不用管其他的分区的配置 leader.replication.throttled.replicas 和 follower.replication.throttled.replicas 什么的，配置了也不会用。因为这里的限流会把这台机器里面的所有跨目录同步的数据流量给统计起来，并进行限流。

如果上面的两个分区都是 100M 那么完成迁移的最小时间是 100M*2 / 1M/s = 200秒。

你知道跨目录迁移的时候,数据是从哪里获取的吗？是从本地，还是从 Leader 分区 Fetch 呢？

是从哪里 Fetch 数据呢？

想知道答案，请继续关注后续文章。下次专门来分析一下跨目录迁移的运维操作和原理解析。

4. 如何手动设置限流

我们分析了分区副本同步过程中的所有情况，也知道了里面的底层原理，想要手动配置限流信息那岂不是随便拿捏。

虽然我这里在写如何设置副本同步限流的教程，但是我仍然不推荐我们主动来设置它。因为很有可能会导致你的副本同步变慢 ISR 跟不上。

这里的配置就是动态配置，实时生效的动态配置。

设置相关配置属性

1) 设置 Broker-0 的 Leader 和 Follower 限流速率


sh bin/kafka-configs.sh   --bootstrap-server xxxxx:9092 --alter  --entity-type brokers --entity-name 0 --add-config leader.replication.throttled.rate=1048576,follower.replication.throttled.rate=1048576

效果如下：


{   "version": 1,   "config": {      "leader.replication.throttled.rate": "1048576",      "follower.replication.throttled.rate": "1048576"   }}

当然，如果设置 replica-alter-log-dirs-throttle 话，更改上面的配置就行了。

2) 设置 Topic1 的某些分区需要进行限流

我们设置 Topic1-1 需要再Broker-0 上进行 Leader 限流，Topic1-2 需要在 Broker-1 上进行 Follower 限流。


sh bin/kafka-configs.sh   --bootstrap-server xxxxx:9092 --alter  --entity-type brokers --entity-name 0 --add-config leader.replication.throttled.replicas=1:0,follower.replication.throttled.replicas=2:1

最终效果 /config/topics/Topic1 新增了以下几个配置：


{   "version": 1,   "config": {      "leader.replication.throttled.replicas": "1:0",      "follower.replication.throttled.replicas": "2:1"   }}

2) 设置 Topic1 的所有分区，在所有 Broker 上都需要进行限流

只需要把值设置为 * 就行了。


sh bin/kafka-configs.sh   --bootstrap-server xxxxx:9092 --alter  --entity-type brokers --entity-name 0 --add-config leader.replication.throttled.replicas=*,follower.replication.throttled.replicas=*

最终效果 /config/topics/Topic1 新增了以下几个配置：


{   "version": 1,   "config": {      "leader.replication.throttled.replicas": "*",      "follower.replication.throttled.replicas": "*"   }}

- EOF -

推荐阅读点击标题可跳转

1、Kafka 架构设计的任督二脉

2、被坑惨了！盘点Kafka一些非比寻常的坑

3、深度剖析：Kafka 请求是如何处理? 看完这篇文章彻底懂了！

看完本文有收获？请转发分享给更多人

关注「ImportNew」，提升Java技能

点赞和在看就是最大的支持❤️