继续前一篇的讨论。前文中提到了两大类配额管理:基于带宽的以及基于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的客户端程序设置请求配额:

p.p1 { margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Menlo; color: #000000; background-color: #ffffff }
span.s1 { }

这里详细说说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请求进行限速的平均时间(毫秒)以及最大时间(毫秒)
05-11 10:49