Kafka Quota 如何做多租户流量隔离？
面试怎么回答
Kafka Quota 可按 user、client-id 或组合维度，限制生产字节率、消费字节率和请求线程占用。落地时先统一认证主体与 client.id，设置保护集群的默认配额，再为关键在线、离线回放和迁移任务分级。超限后 Broker 返回节流时间，客户端变慢而不是丢消息，所以要监控 throttle time、延迟和 Broker 线程。Quota 是隔离手段，不替代容量规划，临时放量还必须自动过期。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
共享 Kafka 集群里，一个回放任务突然把历史数据全速灌入，其他业务 Producer 延迟升高、Consumer 拉取变慢。集群没宕机，但所有租户都被一个“大嗓门”拖住了。
Quota 的作用不是让 Kafka 更快，而是限制单组客户端可以占用的带宽和请求处理资源。
Kafka Quota 通过 user、client-id 或组合维度限制生产、消费字节率和请求线程占用；设计重点是身份可区分、默认值合理、节流可观测与例外可回收。
Quota 控制三类核心资源
生产配额限制写入字节率，消费配额限制拉取字节率，请求率配额限制客户端占用 Broker 网络和 I/O 线程的时间比例。三者解决的瓶颈不同，只有带宽配额不能防住大量小请求造成的线程压力。
先让租户身份稳定可识别
Kafka 可按 user principal、client-id 或两者组合配置。生产环境要规范认证主体和 client.id，避免所有应用都使用默认名称，也避免实例号写进 client-id 导致配额碎片化。配额通常由同一客户端组共享。
默认配额负责保护底线
为未显式配置的用户或客户端设置默认值，防止新任务无上限进入集群；关键在线链路再配置更高额度，离线回放、迁移和压测使用独立身份与较低上限。额度要结合 Broker 数量，因为带宽限制按 Broker 生效。
超限后是节流而不是丢消息
Broker 计算超额使用并返回 throttle time，客户端在对应时间内延迟请求。业务会看到延迟和吞吐下降，而不是直接数据丢失。监控应覆盖 throttle time、请求延迟、字节率、失败和 Broker 线程利用率。
配额与容量规划不能互相替代
Quota 能阻止某个租户垄断资源，但无法增加磁盘、网络和线程总容量。若所有租户都达到合理额度后集群仍饱和，就需要扩容、迁移或拆集群，而不是继续把每个额度都压低。
临时放量必须有过期机制
大促、回放和迁移常需要短时提高配额。变更应记录负责人、原因、开始与结束时间，并自动回收；否则临时高配额会变成永久缺口。上线前用阶梯压测验证节流是否符合预期。
参考资料
- Apache Kafka 4.2：Design - Quotas：https://kafka.apache.org/42/design/design/#quotas