限流与配额怎么处理
被限流是常态而不是异常：客户端要正确响应 429，按响应里给出的等待时间退避、把任务排队、对用户分级提示；服务端则做双层限流，租户级防止单租户挤占，全局级保护上游与自身容量。两侧配合才能在高峰期把可用性守住。
基本信息
| 客户端动作 | 按响应等待时间退避，任务排队而不是原地重试 |
|---|---|
| 服务端结构 | 租户级 + 全局级双层限流，防止单租户占满配额 |
| 配额管理 | 按租户分级设置，接近上限时提前提醒 |
| 指标 | 拒绝率、排队时长、配额余量三项一起看 |
| 用户提示 | 区分“稍后自动重试”与“配额已用尽”，避免误导 |
典型使用场景
- 批量调用上游：整批降速排队，而不是每条各自猛冲
- 租户配额告急：关闭非关键增强功能，把配额留给核心请求
- 多租户平台：按租户限流，防止一个客户的高并发拖慢所有人
- 高峰期保护：全局限流触发时优先拒绝低优先级任务
- 容量规划：用拒绝率与排队时长判断何时需要扩容
限流应对伪代码
限流应对伪代码
if resp.status == 429:
wait = retry_after(resp) or backoff() # 优先用上游给的等待时间
schedule_retry(wait)
# 同一租户的排队任务整体降速，避免占满配额
degrade_optional_features() # 配额余量低于 10% 时先停非关键增强
# 指标: 拒绝率、排队时长 P95、配额余量、重试次数分布限流场景与应对
| 场景 | 应对 | 避免 |
|---|---|---|
| 单次 429 | 按等待时间退避后重试 | 立刻原样重发 |
| 持续 429 | 整批降速排队并告知用户 | 多条任务同时重试 |
| 租户配额接近上限 | 先停非关键功能 | 悄悄降低质量而不提示 |
| 全局限流触发 | 按优先级拒绝低优任务 | 无差别拒绝导致核心不可用 |
重试与限流是一对：如果重试策略不考虑配额，退避只解决了时序问题，总请求量仍然会超过配额，限流会持续存在。