Ch11-Kafka 之 Quota

Ch11-Kafka 之 Quota

April 22, 2019
Apache Kafka
kafka

kafka Quota

1. 实现原理 #

Kafka 集群可以对客户端请求进行 quota，控制集群资源的使用。Kafka broker 可以对客户端做两种类型资源的配额限制，同一个 group 的 client 共享 quota。

  • 定义字节率的阈值来限定网络带宽的 quota。 (从 0.9 版本开始)
  • request 请求率的 quota，网络和 I/O线程 cpu 利用率的百分比。 (从 0.11 版本开始)

1.1 Network Bandwidth Quotas #

Network Bandwidth Quotas 使用字节速率来定义每个 group 的客户端的共享 Quotas，默认情况下，每个 client 都会收到由集群配置的固定 quota(X bytes/sec)。这个quota是在每个broker基础上定义的。每个client在抵达这个quota之前，每秒可以向单个broker 发布/拉取任意bytes(小于给定的quota)的数据。

1.2 Request Rate Quotas #

Request Rate Quotas 定义了一个客户端可以使用 request handler I/O threads 和 network threads 在一个 quota 窗口内百分比。n% 的 quota 代表一个线程的 n%的使用率，所以这种 quota 的最大可配置参数是 ((num.io.threads + num.network.threads) * 100)%之上的。由于分配给 request handler I/O threads 和 network threads 的数量是基于 broker 的核数，所以 request rate quotas 表示的是共享 quota 的每组 client 可以使用的 CPU 百分比

2. 注意事项 #

默认情况下，每个 client group 都可以接收到由 cluster 配置的 quota。This quota is defined on a per-broker basis。每个 client 在达到这个配置的阈值之前，可以随意使用。之所以在每个 broker 层面定义 quota，而不是在 cluster 层面定义 quota，主要是因为在 cluster 层面定义 quota 需要一种机制来同步每个 broker 的 quota 的用量，这个实现起来比较复杂。

当检测到某个 request 超过了 quota，broker 首先会去计算这个请求的需要的延迟时间，然后根据这个延迟时间延迟返回 response。对于 fetch request，response 将不会返回数据，接着该 broker 将不会响应来自该 client 的请求，直到这个延迟时间耗尽。对于 kafka client，如果发现了这种带延迟的 response，在延迟期间，将不再向 broker 发送请求。

对于一些老版本的 client，不会理会这种带延迟的 response，会依旧向 broker 发送请求，broker 通过经过 sockets channel 实现的背压仍然可以实现对这种 client 的限制。那些向限制的 channel 发送 request 的 client 在延迟结束之后，才会收到 response。

Byte-rate 和 thread utilization 使用多个小窗口来衡量（例如 1 秒 30 个窗口），以便快速的检测和修正违反 quota 的 request。一般情况下，如果使用较大的测量窗口（例如 30 秒 10 个窗口）可能会导致大量的突发流量，接着出现长时间的延迟，最后严重影响客户体验。

如果一个集群有 x 个 broker，一个 topic 有多个分区，这里假定是 y 个分区 (x > y)。对于一个 client 限制 quota 为 n bytes/s如果一个client对应一个topic，那么站在producer的角度而言，那么被限速大小应该是 y * n bytes/s，如果有m个producer，那么理想情况下，每个producer的被限速大小应该是 y * n / m bytes/s。
如果一个集群有 x 个 broker，一个 topic 有多个分区，这里假定是 y 个分区 (x < y)。对于一个 client 限制 quota 为 n bytes/s如果一个client对应一个topic，那么站在producer的角度而言，那么被限速大小应该是x * n bytes/s。如果有m个producer，那么理想情况下，每个producer的被限速大小应该是 x * n / m bytes/s。
如果有多个 producer，并且它们使用同一个 client。也就是说，假定最终限额为 1MB/s，如果 producerA 使用了256KB/s，那么 producerB 就只能使用 768KB/s了。
最混乱的是有两个 topic，且每个 topic 的分区数（小于 broker 数量）不一样，然后两个 producer 使用同一个 client（配置为 1bytes/s），那么站在每个 producer 的角度来看，其理论被限速大小应该是 x * 1 bytes/s和 y * 1 bytes/s，经过测试，发现两个producer的被限速大小约为 (x + y)/2 bytes/s。