关于Kafka配额的讨论(2)

继续前一篇的讨论。前文中提到了两大类配额管理：基于带宽的以及基于CPU线程使用时间的。本文着重探讨基于CPU线程时间的配额管理。

定义

这类配额管理被称为请求配额(request quota)，管理起来非常简单，能够调节的参数只有一个：request_percentage。该参数是一个百分比。假设设置为20，则表示20%，即Kafka broker线程处理客户端请求时不会超过20%的线程时间。根据官网描述，它严格的定义为：该配额指定了一个客户端在单个配额时间窗口(quota.window.size.seconds)内能够占用请求处理线程(request handler I/O thread)和网络线程(network thread)的最长时间百分比。这里简单解释一下这两个线程的区别：

• 请求处理线程：执行真正的请求处理逻辑，线程个数由num.io.threads指定，默认是8个
• 网络线程：处理broker与客户端之间的连接、请求发送、响应发送等事宜，线程个数由num.network.threads指定，默认是3个

简单来说，每当客户端发送请求给broker时，网络线程通过Socket接收请求后会放入一个请求队列，而请求处理线程定时从该队列中获取请求，处理之并将结果放入到响应队列，之后再由网络线程发送之。

okay，言归正传，定义请求配额的作用域是单个线程。也就是说，我们设置request_percentage = n，那么n生效的范围是一个线程，故这类配额的最大值就是(num.network.threads + num.io.threads) * 100。如果是默认参数的话就是1100。随着客户端向broker不断发送请求，broker会实时地比较当前请求处理时间百分比与该配额值的关系。一旦发现该值超过了预设的限定值则自动触发限速逻辑：等待一段时间后再返回response给客户端。至于如何计算出这段等待时间，请参加上一篇中的公式，这里不再赘述。

注意：以上给出的定义以及对定义的表述是根据官网KIP总结得来，我在这里想说一些不同的意见，如果各位看官有不同意见敬请批评指正。根据官网定义，它的理论最大值由两个线程相加后*100得出，但查询源代码之后我发现它计算的值实际上就是请求被处理的时间——即broker处理完请求的时间 - 请求从请求队列中出队的时间，因此这实际上和网络线程无关。

设置

下面来看如何设置。设置方法和之前给予带宽的配额设置方法一样，可以为client、user或user+client设置。比如下列命令就是给所有配置了client.id = clientA的客户端程序设置请求配额：

bin/kafkconfigs.sh --alter --add-config request_percentage=50 --zookeeper localhost:2181 --entity-type clients --entity-name clientA

这里详细说说request_percentage=50的含义。从上面的定义可知，这是表示50%，那么具体是什么意思呢？ 它表示的是请求处理线程需要花费1秒的百分之多少去处理这个请求。假设broker端处理一个PRODUCE请求花费了430ms，那么我们说该broker花费了1秒的43%去处理请求，小于我们设定的50，因此该请求不会被限速，倘若处理某个PRODUCE请求花费了700ms，则当前配额值达到了70%，超过了50%，此时broker会开启限速逻辑延缓此PRODUCE请求的响应发送。

设置请求配额的意义

引入请求配额主要是为了防止客户端过快地发送请求从而彻底压垮broker。一个简单而有效的Dos攻击就是启动上百个设置了fetch.max.wait.ms = 0的consumer程序同时连入Kafka集群。另外， 请求配额实现了比较基础的CPU资源调度，这对于有Kafka多租户需求的用户来说也是一个非常好的选择。

监控

用户能够根据客户端提供的两个JMX指标来监控请求配额的执行情况：

• producer: produce-throttle-time-avg和produce-throttle-time-max，分别统计了该broker对PRODUCE请求进行限速的平均时间（毫秒）以及最大时间（毫秒）
• consumer：fetch-throttle-time-avg和fetch-throttle-time-max，分别统计了该broker对FETCH请求进行限速的平均时间（毫秒）以及最大时间（毫秒）