Kafka Quotas：如何限制 Producer 和 Consumer 的流量

验证：不限速时，真实的吞吐量基线

命令 · shell $ kafka-producer-perf-test.sh --topic quota-demo --num-records 200000 --record-size 500 \ --throughput -1 --producer-props client.id=quota-test-client

真实实测 · 本机执行输出

200000 records sent, 68728.52 records/sec (32.77 MB/sec),
  782.53 ms avg latency, 1207.00 ms max latency

验证：给这个client.id设置1MB/秒的配额，吞吐量真实被精确摁住

命令 · shell $ kafka-configs.sh --alter --entity-type clients --entity-name quota-test-client \ --add-config 'producer_byte_rate=1048576' $ kafka-producer-perf-test.sh --topic quota-demo --num-records 200000 --record-size 500 \ --throughput -1 --producer-props client.id=quota-test-client

真实实测 · 本机执行输出

200000 records sent, 2159.80 records/sec (1.03 MB/sec),
  25943.97 ms avg latency, 34922.00 ms max latency

配置的配额是1048576字节/秒(1MB/秒)，真实测出来的吞吐量是1.03MB/秒——几乎完全对上。真实更值得注意的是延迟的变化：平均延迟从782毫秒真实暴涨到25944毫秒，涨了33倍。这揭示了Kafka quota真实的实现机制：它不是直接拒绝超额的请求，而是让broker真实故意延迟对这个client的响应——producer这边感知到的就是"请求变慢了"，而不是"请求被拒绝了"，这样应用层不需要写额外的重试逻辑去应对配额限制，它自然会被producer内部的缓冲和背压机制消化掉，只是真实的代价是延迟变得很不稳定。

分步演示：quota真实是怎么把吞吐量摁住的

每一步都是本文上面用kafka-producer-perf-test.sh跑出来的原始结果。

配额真实通过拖慢响应实现，不是直接拒绝

这一步新验证的配置

参考与说明

数据来自本机3节点Kafka 4.3.1集群，topic quota-demo，通过kafka-configs.sh对entity-type clients设置producer_byte_rate配额。
没有验证：consumer_byte_rate和request_percentage(CPU时间配额)这两种真实的其它配额类型；多个client共享同一份配额时真实的分配方式。

下一篇 · KAFKA 内部原理 69

Kafka 应该监控哪些指标