“接口已经配置了每分钟 100 次请求，为什么流量高峰时仍然把数据库打满？”限流规则是否存在，只是第一步；真正重要的是限流发生在哪一层、按什么维度计数，以及多实例是否共享状态。
固定窗口的边界问题
固定窗口实现简单，但窗口交界处可能出现两倍突发：上一分钟末尾放行 100 次，下一分钟开头又放行 100 次。对于登录、短信和高成本查询，这个瞬时峰值可能已经超过后端承受能力。
滑动窗口能降低边界突发，但需要保存更多时间片。令牌桶则允许配置一定的突发容量，同时控制长期平均速率，更适合有短时峰值但需要稳定平均吞吐的接口。
先定义限流维度
只按 IP 限制会误伤共享出口，也挡不住分布式请求；只按用户限制又可能让匿名接口失去保护。实际设计通常要结合用户、IP、API 密钥、租户和接口成本分层计数。
高风险操作还应增加业务维度，例如同一账户的验证码发送、密码重置和支付确认。限流不是身份认证的替代品，匿名请求仍要先经过基础校验。
多实例必须共享状态
如果每个应用实例都在本地内存中计数，负载均衡后总额度会随着实例数量放大。可以使用 Redis 等共享存储，但要考虑网络延迟、键过期、原子递增和故障降级。
降级策略必须提前定义：共享计数服务不可用时，是严格拒绝、临时放宽，还是只保护高风险接口。不能让异常路径默认绕过限流。
观察四类指标
至少记录限流命中数、被拒请求的维度、后端响应耗时和共享存储错误。响应头可以返回剩余额度和重试时间，但不要泄露内部键名或用户隐私。通过这些指标，才能区分“规则太松”“算法边界突发”和“后端本身变慢”。
上线前用固定请求速率、窗口边界、多实例和共享存储故障四组测试验证。每组都记录预期放行量、实际放行量和恢复时间。
返回码也要统一。通常可以使用 429 表示请求过多，并通过 `Retry-After` 告知客户端何时重试。客户端不能在收到 429 后立即无限重试，否则会把一次限流放大成新的流量峰值。服务端还应为内部调用设置单独额度，避免批处理任务消耗公共 API 的全部容量。
限流规则需要版本化。调整窗口、额度或维度时，记录变更原因、受影响的租户和回滚方式；对关键接口先做小范围灰度。这样出现误伤时，可以快速判断是流量变化还是策略变更造成的。
如果你希望系统学习 Web 安全、接口防护和安全工程设计，可以参考马士兵网络安全课程学习入口：
