这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
限流问题
场景
用户量继续增长，我发现了一些异常情况。
问题发现
某天，服务器响应突然变慢。
我查了一下监控，发现：
Top 10 用户（最近 1 小时）
User 123 15,000 次/小时
User 456 800 次/小时
User 789 600 次/小时
User 101 500 次/小时
User 123 在 1 小时内调用了 15000 次！
平均每秒：15000 / 3600 ≈ 4.2 次
这个用户在疯狂调用 API，影响了其他用户。
问题分析
我查看了这个用户的使用情况：
切换到查询模式，可以看到统计查询的执行意图和结果。
特征：
- 24 小时不间断调用
- 每小时约 1000-1500 次
- 很有规律的调用模式
结论：这是一个自动化程序！
影响
这个用户的疯狂调用对系统的影响：
1. 性能影响
正常情况：
- QPS（每秒请求数）：5
- 平均响应时间：50ms
- 服务器 CPU 使用率：30%
User 123 加入后：
- QPS：10（翻倍）
- 平均响应时间：150ms（变慢 3 倍）
- 服务器 CPU 使用率：70%2. 资源占用
User 123 占用资源：
- 外部 API 调用量：5%（15000/300000）
- 服务器 CPU 时间：30%
- 数据库连接：常驻 1-2 个
更糟糕的是：
- 挤占了正常用户的资源
- 影响了整体用户体验3. 不公平
正常用户：
- 每天 100 次调用
- 按套餐付费
User 123：
- 每天 36000 次调用
- 同样的套餐这不公平！
限流目标
我决定实现限流机制。
限流目标
- 保护系统稳定性
- 保证公平性
- 区分不同套餐
限流策略
| 套餐 | 每日限额 | 每秒限额 | 突发限额 |
|---|---|---|---|
| 免费版 | 1000 次 | 1 次/秒 | 10 次 |
| 基础版 | 10000 次 | 10 次/秒 | 100 次 |
| 专业版 | 100000 次 | 100 次/秒 | 1000 次 |
练习
练习 1
如果 User 123 是一个正常付费用户，只是在做批量任务，你还会直接封禁他吗？你会怎样设计限流规则，既保护系统，又尽量不误伤用户？
参考答案 (3 个标签)
限流 公平性 用户体验
不应该一上来就封禁。更好的做法是把“恶意”和“高频正常使用”分开处理。
可以这样设计：
- 按套餐设置基础限额：免费版、基础版、专业版有不同的每日限额和每秒限额。
- 允许短时间突发：用突发额度处理批量任务，避免用户偶尔集中调用就被拦住。
- 超过阈值先降速：先返回限流提示和剩余额度，而不是直接封号。
- 异常行为再风控：如果出现大量错误参数、撞库式请求、绕过认证等行为，再进入封禁或人工审核。
验证时要看被限流请求里是否有正常业务场景。如果正常用户频繁被拦，说明阈值或突发额度设计得太保守。