本章进度 7 / 18
39%
正文已完成
L300限流是在保护容量，不是在惩罚用户
理解固定窗口、令牌桶、并发上限与排队如何保护下游服务。
先用本课建立“限流重试”的基本直觉，后面的判断和练习才不会只靠记结论。
建议按完整课程顺序先看上一课；如果术语陌生，可以随时回补。
- 无需安装新工具
- 直接阅读并完成本页理解检查
没有限流，突发请求可能让线程、连接池和第三方配额同时耗尽，最终所有用户都失败。限流的目标是让系统在已知容量内保持可预测，并告诉调用者何时、怎样重试。
能根据容量风险说明为何限流，并为被限制请求设计明确反馈。
核心概念
先把关键判断说清楚
速率与并发不同
每分钟请求数控制长期吞吐，同时进行的请求数控制瞬时资源占用；慢请求尤其需要并发上限。
令牌桶允许有限突发
令牌按速率补充并可积累少量余额，既限制长期平均，又允许短时合理峰值。
拒绝也要有契约
被限流时返回明确状态、重试时间和请求标识，调用方才能采取退避而非盲目重发。
案例拆解
批量生成摘要压垮模型接口
用户一次提交 500 篇文章，前端同时发起请求，模型配额耗尽并拖慢普通单篇任务。
- 01
入口限制每个账户每分钟提交量，并将批量任务转入队列。
- 02
模型调用侧限制全局并发，给交互请求保留固定容量。
- 03
超出时返回 429、Retry-After 和任务状态入口。
案例结果
批量任务不再吞掉全部配额，普通用户仍能获得可预测响应。
提交前练习
现在轮到你
为一个调用成本较高的接口设计最小限流策略。
选做练习：本节练习可用于加速你巩固，但不影响继续学习。
内容会自动保存在当前设备
查看参考答案与评分标准
参考答案
接口是图片生成；保护 GPU 并发 8；按账户每分钟 20 次且全局并发 8，允许 5 次短时突发；超限返回 429、预计等待秒数与排队入口。
评分标准
- 限制对应真实瓶颈
- 主体选择不会轻易误伤共享用户
- 超限反馈可被调用方执行
本课收口 · 理解检查
用 30 秒确认你理解了
用 30 秒理解检查确认你抓住了重点；阅读标记、练习和总结都不设硬门槛。
你现在更接近哪一种状态？
尚有必填项未完成，请补齐后再继续。
资料来源
继续核对与延伸阅读
本课内容最近更新于 。
- Monitoring Distributed Systems↗reference · 核对日期 2026-08-23
- OpenTelemetry Signals↗official-docs · 核对日期 2026-08-23