Kafka自0.9.0.0版本引入了配额管理(quota management),旨在broker端对clients发送请求进行限流(throttling)。目前Kafka支持两大类配额管理:

  • 网络带宽(network bandwidth)配额管理:定义带宽阈值来限制请求发送速率,阈值单位是字节/秒,即bytes/s。该功能是0.9.0.0版本引入的
  • CPU配额管理:定义CPU使用率阈值来限制请求发送速率,阈值以百分比的形式给出,如quota = 50表示50%的CPU使用率上限。该功能是0.11.0.0版本引入的

本文主要讨论网络带宽配额管理。关于CPU配额管理的部分我们将在下一篇中进行讨论。

一、配额能做什么?

设置了基于带宽的配额之后,Kafka能够做到:

1. 限制follower副本拉取leader副本消息的速率

2. 限制producer的生产速率

3. 限制consumer的消费速率

二、配额作用域

目前可以在3个层级上设置配额:

1. client id

2. user

3. user + client id

第一种是client id,即新版本clients端的通用参数client.id设置的值。一旦为某个client id设置了配额,所有具有该client id的clients段程序都将受到该配额的限制。

第二种是user,为启用认证之后位于认证体系中的某个用户主体(user principal),比如一个Kerberos用户:user1/kafka.host1.com@REALM,Kafka解析出来的用户名是'user1’。当然我们可以设置sasl.kerberos.principal.to.local.rules参数修改这种解析规则,不过这不在本文的讨论范围内。

第三种就是user + client id,实际上是包含前两种的一个二元组。它是最细粒度化的配额管理作用域。

当然,这3种作用域还可以设置各自的默认值配额(默认是没有配额的,即默认值通常是无穷大),包括:client id作用域默认值、user作用域默认值、user + client id作用域默认值,其中最后一项又可细分为4个子作用域,即

  • user作用域默认值 + client id作用域指定值
  • user作用域指定值 + client id作用域指定值
  • user作用域默认值 + client id作用域默认值
  • user作用域指定值 + client id作用域默认值

因此,实际上总共有8种可能的配额作用域设置值,它们的优先级关系依次如下(从高到低):

  • user作用域指定值 + client id作用域指定值(即为user + client id设置了特定值配额)
  • user作用域指定值 + client id作用域默认值(为user设置了特定值配额,为client id设置了默认值配额)
  • user作用域(为user设置了特定值配额)
  • user作用域默认值 + client id作用域指定值(为user设置了默认值配额,为client id设置了特定值配额)
  • user作用域默认值 + client id作用域默认值(为user和client id设置了默认值配额)
  • user作用域默认值(为user设置了默认值配额)
  • client id作用域(为client id设置了特定值配额)
  • client id作用域默认值(为client id设置了默认值配额)

当多条配额规则冲突时我们可以根据以上规则确定应用的是哪一条。举个例子,我们为user = 'good-user'的用户配置了100MB/s的配额,同时为[user='good-user', client id = 'producer-1']设置配额为50MB/s,那么当good-user用户使用名为‘producer-1’的producer发送消息时Kafka保证它的请求处理速率不会超过50MB/s,即第二条规则覆盖了第一条规则。

三、如何设置?

我们根据第一小节中提到的3种功能来分别讨论。

3.1 限制follower副本拉取leader副本消息的速率

方法1: 设置broker端动态参数leader.replication.throttled.rate和follower.replication.throttled.rate。

前者控制leader副本端处理FETCH请求的速率,后者控制follower副本发送FETCH请求的速率。既然是动态参数,说明它们的值可以实时修改而无需重启broker。假设我要为broker 0和1设置follower和leader限速为100MB/s,方法如下:

bin/kafka-configs.sh --zookeeper localhost:2181 --alter --add-config 'leader.replication.throttled.rate=104857600,follower.replication.throttled.rate=104857600' --entity-type brokers --entity-name 0
Completed Updating config for entity: brokers '0'.

bin/kafka-configs.sh --zookeeper localhost:2181 --alter --add-config 'leader.replication.throttled.rate=104857600,follower.replication.throttled.rate=104857600' --entity-type brokers --entity-name 1
Completed Updating config for entity: brokers '1'.

执行下列命令检查下是否配置成功:

bin/kafka-configs.sh --zookeeper localhost:2181 --describe --entity-type brokers
Configs for brokers '0' are leader.replication.throttled.rate=104857600,follower.replication.throttled.rate=104857600
Configs for brokers '1' are leader.replication.throttled.rate=104857600,follower.replication.throttled.rate=104857600

同时,还必须为topic设置leader.replication.throttled.replicas和follower.replication.throttled.replicas 。这组参数需要指定要限速的副本,如果想让topic的所有副本都生效,可以使用*通配符:

bin/kafka-configs.sh --zookeeper localhost:2181 --alter --add-config 'leader.replication.throttled.replicas=*,follower.replication.throttled.replicas=*' --entity-type topics --entity-name test

Completed Updating config for entity: topic 'test'.

方法2:执行分区重分配时设置

在使用kafka-reassign-partitions.sh(bat)脚本执行分区重分配时也可以设定 ,方法如下(依然设置成100MB/s):

bin/kafka-reassign-partitions.sh --zookeeper localhost:2181  --execute --reassignment-json-file to-be-reassigned.json --throttle 104857600

实际上,该脚本通过--throttle参数间接设置了leader.replication.throttled.rate和follower.replication.throttled.rate参数,故本质上和方法1是相同的。值得注意的,该脚本只会对参与到分区重分配的broker设置配额,对其他broker是不起作用的。

3.2 限制producer端速率

方法1: 设置broker端静态参数quota.producer.default参数

比如:在server.properties中加入quota.producer.default=15728640将限制所有连入该broker的producer的TPS全部降到15MB/s以下。设置此参数的好处是能够限制集群上的所有producer,但劣处也在于此,对所有producer“一视同仁”,无法细粒度地对个别clients进行设置。故社区在0.11.0.0版本将其标记为"Deprecated",并始终推荐用户使用动态参数的方式来为producer端进行限速。

方法2:设置动态参数producer_byte_rate

首先演示为所有client id设置默认值,假设我们为所有producer程序设置其TPS不超过20MB/s,即20971520B/s,命令如下:

bin/kafka-configs.sh --zookeeper localhost:2181 --alter --add-config 'producer_byte_rate=20971520' --entity-type clients --entity-default
Completed Updating config for entity: default client-id.

然后我们为client.id=‘producer-1'的producer单独设置其TPS不超过10MB/s,即10485760B/s,命令如下:

bin/kafka-configs.sh --zookeeper localhost:2181 --alter --add-config 'producer_byte_rate=10485760' --entity-type clients --entity-name producer-1
Completed Updating config for entity: client-id 'producer-1'.

下面做个简单的试验验证下,我们启动两个client.id是producer-1和producer-2的producer程序去验证它们的TPS小于设置的阈值:

bin/kafka-producer-perf-test.sh --topic t1 --throughput -1 --num-records 9000000 --record-size 500 --producer-props bootstrap.servers=localhost:9092 acks=-1 client.id=producer-2
......
9000000 records sent, 41632.936278 records/sec (19.85 MB/sec), 1563.41 ms avg latency, 6488.00 ms max latency, 912 ms 50th, 5576 ms 95th, 6169 ms 99th, 6474 ms 99.9th.

可见producer-2的TPS被限制在了20MB/s以下。接下来我们试试producer-1(因为其阈值设置得小,故这次我们少发一些消息以加速整个试验进程):

bin/kafka-producer-perf-test.sh --topic t1 --throughput -1 --num-records 3000000 --record-size 500 --producer-props bootstrap.servers=localhost:9092 acks=-1 client.id=producer-1
......
3000000 records sent, 20771.020273 records/sec (9.90 MB/sec), 3128.39 ms avg latency, 8960.00 ms max latency, 986 ms 50th, 8784 ms 95th, 8941 ms 99th, 8953 ms 99.9th.

为user设置配额的方法与client id类似,设置全局默认值:

bin/kafka-configs.sh --zookeeper localhost:2181 --alter --add-config 'producer_byte_rate=20971520' --entity-type users --entity-default
Completed Updating config for entity: default user-principal.

为特定用户(user1)设置:

bin/kafka-configs.sh --zookeeper localhost:2181 --alter --add-config 'producer_byte_rate=20971520' --entity-type users --entity-name user1

Completed Updating config for entity: user-principal 'user1'.

最后是设置(user + client id)作用域设置配额。依然是全局默认值:

user1的client id默认配额

bin/kafka-configs.sh --zookeeper localhost:2181 --alter --add-config 'producer_byte_rate=20971520' --entity-type users --entity-name user1 --entity-type clients --entity-default
Completed Updating config for entity: user-principal 'user1', default client-id.

producer-1的user默认配额

bin/kafka-configs.sh --zookeeper localhost:2181 --alter --add-config 'producer_byte_rate=20971520' --entity-type users --entity-default --entity-type clients --entity-name producer-1
Completed Updating config for entity: default user-principal, client-id 'producer-1'.

然后是特定值:

user1 + producer-1的配额值

bin/kafka-configs.sh --zookeeper localhost:2181 --alter --add-config 'producer_byte_rate=20971520' --entity-type users --entity-name user1 --entity-type clients --entity-name producer-1
Completed Updating config for entity: user-principal 'user1', client-id 'producer-1'.

3.3 限制consumer端速率

和producer类似,也存在两种方法:

方法1: 设置broker端静态参数quota.consumer.default参数

与quota.producer.default完全相同的参数,只不过是适用于consumer端的,不再赘述。

方法2:设置动态参数consumer_byte_rate

与producer_byte_rate完全对等的参数,只是适用于consumer端的,不再赘述

四、配额算法

简单来说,我们假设当前实际值是O,T是我们设置的阈值,而W表示某一段时间范围,我们希望在W时间内O能够下降到T以下(如果O本来就比T小,则什么都不用做),那么broker端就需要延缓等待一段时间。如果假设这段时间是X,那么以下等式成立:

O * W = (W + X) * T 

由此得出X = (O - T) / T * W。这就是Kafka用于计算等待时间的公式。当然在具体实现时,Kafka提供了两个参数来共同计算W:W = quota.window.num * quota.window.size.seconds。前者表示取样的时间窗口个数,后者表示时间窗口大小。特别是后者会在CPU配额管理中用到。不过在本文中,我们可以统一使用W即可。当Kafka检测到配额透支情况发生时,broker不会返回错误而是直接将超支配额的客户端进行减速处理。它会计算需要X然后令client强制sleep直至令其降到配额之下。该方法对于client来说完全透明。同时,client也不需要自己实现任何特殊的策略来应对。事实上,有的client在应对这种情况时会不停地重试反而加剧了本要解决的问题。

五、可能的问题

如前所述,限速是在broker端执行的!broker端故意“sleep”来限速的做法虽然对clients端透明,但确实也会引起clients端请求的超时,故在实际使用过程中适当地增加request.timeout.ms对于启用了限速的Kafka环境而言就显得非常必要了。

Kafka配额讨论(流量限制)的更多相关文章

  1. 关于Kafka配额的讨论(2)

    继续前一篇的讨论.前文中提到了两大类配额管理:基于带宽的以及基于CPU线程使用时间的.本文着重探讨基于CPU线程时间的配额管理. 定义 这类配额管理被称为请求配额(request quota),管理起 ...

  2. 关于Kafka配额的讨论(1)

    Kafka自0.9.0.0版本引入了配额管理(quota management),旨在broker端对clients发送请求进行限流(throttling).目前Kafka支持两大类配额管理: 网络带 ...

  3. kafka配额控制

    转载请注明地址http://www.cnblogs.com/dongxiao-yang/p/5217754.html Starting in 0.9, the Kafka cluster has th ...

  4. kafka中的配额管理(限速)机制

    kafka支持配额管理,从而可以对Producer和Consumer的produce&fetch操作进行流量限制,防止个别业务压爆服务器.本文主要介绍如何使用kafka的配额管理功能. 1 K ...

  5. kafka 基础知识梳理及集群环境部署记录

    一.kafka基础介绍 Kafka是最初由Linkedin公司开发,是一个分布式.支持分区的(partition).多副本的(replica),基于zookeeper协调的分布式消息系统,它的最大的特 ...

  6. Kafka史上最详细原理总结

    https://blog.csdn.net/ychenfeng/article/details/74980531 Kafka Kafka是最初由Linkedin公司开发,是一个分布式.支持分区的(pa ...

  7. Kafka原理总结

    Kafka Kafka是最初由Linkedin公司开发,是一个分布式.支持分区的(partition).多副本的(replica),基于zookeeper协调的分布式消息系统,它的最大的特性就是可以实 ...

  8. Apache Kafka: 优化部署的10个最佳实践

    原文作者:Ben Bromhead      译者:江玮 原文地址:https://www.infoq.com/articles/apache-kafka-best-practices-to-opti ...

  9. 图文了解 Kafka 的副本复制机制

    让分布式系统的操作变得简单,在某种程度上是一种艺术,通常这种实现都是从大量的实践中总结得到的.Apache Kafka 的受欢迎程度在很大程度上归功于其设计和操作简单性.随着社区添加更多功能,开发者们 ...

随机推荐

  1. Angular material mat-icon 资源参考_Warning

    ul,li>ol { margin-bottom: 0 } dt { font-weight: 700 } dd { margin: 0 1.5em 1.5em } img { height: ...

  2. autokeras 在windows10下的安装与使用

    注意:autokeras只适用于python3.6 先打开命令行(cmd), 输入 python --version 查看python版本,是否需要降级和升级. 降级的命令如下: conda inst ...

  3. AC自动机模板题

    AC自动机学习博客 AC自动机理解要点: 1)fail指针指向的是每个节点,在字典树上和这个节点后缀相同的最长单词,每次都这样匹配,必定不会漏过答案. 2)字典树建立后,会在bfs求fail阶段把字典 ...

  4. 矩阵快速幂--51nod-1242斐波那契数列的第N项

    斐波那契额数列的第N项 斐波那契数列的定义如下: F(0) = 0 F(1) = 1 F(n) = F(n - 1) + F(n - 2) (n >= 2) (1, 1, 2, 3, 5, 8, ...

  5. OPPO R11s在哪里打开Usb调试模式的简单方法

    就在我们使用pc链接安卓手机的时候,如果手机没有开启usb调试模式,pc则不能够成功读到我们的手机,如果遇到此情况我们需要找方法将手机的usb调试模式打开,本文我们记录一下OPPO R11s如何开启u ...

  6. Python用于http/https接口自动化

    本接口自动化框架主要用到的类: 1. unittest:组织测试用例 2. requests:http/https请求 3. HTMLTestRunner:生成测试报告 4. Dingtalkchat ...

  7. git遇到的常见错误整理

    远程仓库与本地代码不一致 解决: git pull --rebase git@gitee.com:l544402029/MUTAO.git 将仓库里的代码pull下来  ,然后重新进行git add ...

  8. Git修改文件

    如果我们修改了本地的某个文件但是没有提交,这时我们用 $ git status可以看到提示,例如我在readme2.txt里面新加了一行,然后查看状态: git status命令可以让我们时刻掌握仓库 ...

  9. sql 查询目标数据库中所有的表以其关键信息

    1.查询目标库中的所有表 SELECT obj.name tablename, ---表名 schem.name schemname, ---表所属的方案 idx.rows, ---一共有几行数组 C ...

  10. 我的Python升级打怪之路【四】:Python之前的一些补充

    字符串的格式化 1.百分号的方式 %[(name)][flags][width].[precision]typecode (name) 可选,用于选择指定的key flags 可选,可供选择的值有: ...