为什么需要限流
API限流是保护后端服务的关键措施。没有限流的API就像没有保险丝的电路，一个恶意客户端或突发流量就可能导致整个服务崩溃。合理的限流策略在保护服务的同时不影响正常用户体验。
限流算法对比
固定窗口计数器
最简单的实现：将时间划分为固定窗口（如1分钟），每个窗口内计数。缺点：窗口边界处可能出现两倍流量突刺（上一窗口末尾+下一窗口开头）。
滑动窗口计数器
改进版，使用加权计算平滑窗口边界。实现方式：当前窗口计数 + 上一窗口计数 * 上一窗口剩余比例。Redis Sorted Set可以精确实现滑动窗口。
令牌桶算法
以固定速率向桶中添加令牌，请求消耗令牌。桶满时多余令牌丢弃。允许一定程度的突发流量（桶容量）。Nginx和Kong的限流插件默认使用此算法。
漏桶算法
请求进入桶中排队，以固定速率处理。严格控制处理速率，适合需要平滑流量的场景。缺点：突发流量全部排队，响应延迟增大。
分布式限流实现
Redis方案
使用Redis的INCR+EXPIRE实现分布式计数器。Lua脚本保证原子性。
API网关方案
在Kong/Envoy等网关层配置限流规则，支持按IP、API Key、用户ID等维度限流。优点：统一管理、对后端服务透明。
限流策略设计
- 多维度限流：全局限流 + 用户级限流 + 接口级限流
- 差异化配额：免费用户100次/小时，付费用户10000次/小时
- 优雅降级：超限后返回429状态码和Retry-After头
- 弹性限流：根据系统负载动态调整限流阈值
监控告警
监控限流触发次数、被限流的用户分布、接口调用量趋势。设置告警：限流触发率超过10%说明配额可能设置过低，需要评估是否调整。