遇到请求突然增多，先别急着把所有接口的限额调低。搜索、登录和读取静态配置的成本不同，统一阈值可能误伤正常用户，也未必挡得住分布式刷量。设计API接口遭恶意请求刷量的限流防护设计，关键是先分清请求身份与接口成本，再决定固定阈值和自适应策略如何配合。
两种限流，各自解决什么问题
固定阈值：规则清楚，适合明确边界
固定阈值是在给定时间内限制请求数。例如，按账号、访问凭证或接口分别设置每秒请求上限。它行为可预测、计算开销低，适合登录尝试、验证码发送、创建订单等需要明确保护边界的操作。缺点是流量变化时不够灵活：阈值太高，资源仍可能被耗尽；太低，活动流量或突发重试可能遭拒。
计数算法也有差异。固定窗口实现简单，但窗口交界处可能出现短时请求叠加；滑动窗口能平滑统计，代价是需要维护更多状态。令牌桶允许有限突发，同时控制长期平均速率，适合存在正常瞬时峰值的接口。
自适应限流：跟随负载，但要设护栏
自适应限流根据服务状态调整放行量，可参考请求队列长度、延迟分位值、数据库连接占用和错误率。当后端接近容量时收紧请求，恢复后逐步放宽。它适合请求波动明显、后端资源共享的服务，但反馈信号若抖动或采样太慢，可能导致限额频繁变化。因此必须设置最低与最高限额、调整幅度和恢复缓冲，不能让算法无限制地降到零或突然放开。
先分层，再决定是否动态调整
API接口遭恶意请求刷量的限流防护设计不应只看单一来源。可对账号或凭证设主要配额，对单个高成本接口设更紧的限制，再补充全局并发上限。比如，列表读取与复杂搜索可以采用不同成本权重；同一账号短时反复提交密码重置请求，则应有独立的操作频率约束。来源标识可辅助判断，但不宜单独作为可信身份，因为共享网络会让多个正常用户看起来相同，攻击者也可能更换来源。
| 方案 | 更适合 | 主要风险 |
|---|---|---|
| 固定阈值 | 单接口成本稳定、规则需要可解释 | 流量变化时可能误拦或保护不足 |
| 自适应限流 | 负载波动大、后端有实时状态指标 | 指标延迟或噪声造成限额震荡 |
| 组合使用 | 既要硬性配额又要保护共享资源 | 规则叠加后需明确优先级 |
按步骤上线，避免把保护变成故障
- 盘点接口。按读写行为、计算成本和业务影响分类，标出登录、搜索、写入等高风险路径。
- 建立基线。在正常业务时段观察各接口的请求速率、延迟和失败比例，按账号或凭证拆分；不要直接照搬其他服务的限额。
- 先设硬上限。为昂贵操作设固定阈值，并按服务能力配置全局并发保护。具体数值应通过压测和逐步放量确定；例如高成本查询可从每账号每秒数次的保守范围开始验证，而非视为通用标准。
- 接入负载信号。只选择与容量直接相关且持续可观测的指标；设置最小配额、最大配额、平滑区间和恢复等待，避免一次短暂尖峰触发剧烈变化。
- 先观察再拦截。初期记录将被限制的请求，检查正常用户是否集中受影响，再启用拒绝策略。超限时返回429，并在适用时提供建议重试时间；同时记录规则、接口和身份维度，便于排查。
选择结论与常见问题
如果接口边界清楚、流量平稳，先用固定阈值，维护简单且容易审计；如果负载起伏明显，且能可靠观测后端状态，再加入带护栏的自适应调整。多数服务可采用“固定配额兜底、自适应保护容量”的组合。评估API接口遭恶意请求刷量的限流防护设计是否有效，不只看拒绝了多少请求，还要核对正常请求成功率、后端负载与误拦情况。
固定阈值是不是越低越安全？
不是。过低会阻断正常突发流量，且攻击者可能转向其他接口。应按接口成本和身份维度分别设定，并观察误拦。
自适应限流能替代固定配额吗？
不建议完全替代。固定配额提供可预期的硬边界，自适应策略负责在系统接近容量时进一步收紧。
没有实时负载指标怎么办？
先用固定阈值、并发限制和日志告警；建立稳定的延迟、队列或资源监控后，再评估是否适合动态调整。
