API限流为什么挡不住突发流量？从算法选择到多实例一致性

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