题目重点：内部团队共享限流服务，精度、隔离、可用性和区域一致性需要明确取舍。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练tenant+resource配额，token bucket允许容量B的突发，补充率r；API带requestID。
- 严格每秒窗口与token bucket语义不同；多region严格全球总额需要集中协调或预分配预算，不许假称最终一致仍严格限额。
解题路线
- gateway调用allow(key,cost)，分片限流状态原子补token并扣费。需要使用服务权威单调时间，避免客户时钟操纵。hot tenant可以独立分片或分层本地配额。
- 全球按region发有限token租约，总分配不超过全球预算；租约过期/epoch交接防双花。区域隔离能继续花剩余配额但不能无授权超发，剩余不均会造成拒绝，需明确性能成本。
- 故障策略按资源分类：风控/昂贵操作倾向fail-close，低风险读可fail-open且限制最大过载窗口。服务metrics记录拒绝、额外授权、延迟及租户公平；灰度双读只对一个权威扣费，不能双扣。
手动走一遍
全局每分钟6000，两个region各3000；区域A瞬时需要5000但没有余量转移时应拒绝或协调，不可两边都拿6000。Redis超时不等于扣费失败；重试相同requestID应返回同一决策，避免同请求重复消耗。
规模与取舍
QPS为Q、平均key更新成本c，分片吞吐受热点key串行化约束；若本地每批租L个token，权威调用可降到约Q/L但引入闲置和精度跨度。
易错点与追问
容易失分的边界
- 计数器读+写两步不是原子限流。
- API超时自动fail-open却没设边界，会把限流服务故障变下游雪崩。
继续深挖
- 滑动窗口要求任意60秒都≤M时，token bucket为何不能直接替代？
- 多租户共享总预算时怎样保证保底与借用不互相饿死？
