redis-cli --eval limit.lua , 'app:42:tenant:9' 1000 60 ab -n 5000 -c 50 https://api.example.com/v1/ping
一个租户的脚本死循环调用，把整个应用的 1000 QPS 配额占满，同应用下另外 40 个租户全部收到 429。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，限流 key 只用了 app_id，没有带用户或租户维度，一个人的流量等于全应用共享一个桶。配额被单点打满后，其他调用方排队也进不来。
「限流维度错误」改完先别急着全量，挑一台机器放半天，真有问题这段时间就能看出来。改完隔一天再看一次，当场正常不代表能稳住。
测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。
处理上按这个顺序：限流 key 改成 app_id 加 tenant_id 的组合；单租户再设一个上限 比如总量的两成；全局桶保留兜底 防止总量被打穿；压测确认单租户打满不影响其他人。
改完只确认一件事：单租户压到上限时其他租户 429 比例为 0 全局 QPS 不超过 1000。