请求突然变多时，单纯封掉某个来源，可能拦不住分布式流量，还会误伤正常用户。应用层请求洪水的速率限制策略，应从具体接口和请求身份入手：先找出最容易被重复调用、处理成本较高的路径，再分别限制单个账号、来源地址和系统整体的请求量。
先确定限制对象，再选阈值
不要给所有请求套用同一条速率线。读取静态信息的接口，与创建订单、发送验证码或执行搜索的接口，资源消耗和滥用风险不同。可以先按一分钟或数秒内的请求日志统计正常峰值，区分匿名访问、已登录用户和内部服务流量，再以峰值为参考留出余量。上线前的阈值只是起点，需结合延迟、错误率和业务时段调整。
- 按账号：适合限制单个用户反复操作；登录前无法识别账号时，不能单独依赖这一层。
- 按来源地址：适合应对少量来源的密集请求；共享网络中的多个正常用户可能共用地址，阈值过低容易误伤。
- 按接口和系统总量：对高成本接口设置更紧的限制，并给整体并发或请求量设置保护上限，避免多个来源同时涌入时拖垮服务。
例如，一个普通查询接口可从每个身份每分钟数十次的量级评估起步；验证码发送、资源导出等敏感或耗时操作，通常需要更低的频率，并增加冷却时间。这里不是通用标准：缓存命中情况、请求复杂度、用户行为和服务容量都会改变合适数值。
按流量形态选择算法
| 方式 | 特点 | 适用情况 |
|---|---|---|
| 固定窗口 | 按固定时间段计数，容易理解和实现；窗口交界处可能短时放过两倍左右的请求。 | 限制简单、允许少量边界波动的接口。 |
| 滑动窗口 | 更平滑地计算最近一段时间的请求数；计数或存储开销相对更高。 | 不希望窗口边缘出现明显突发的场景。 |
| 令牌桶 | 按设定速率补充令牌，并允许有限突发；桶容量决定突发余量。 | 正常流量有短时波动、又需要控制长期平均速率的接口。 |
应用层请求洪水的速率限制策略不必只选一种算法。常见做法是令牌桶控制单个身份的突发量，再以接口级并发上限保护耗时操作；对验证码等动作，还可增加账号与地址组合限制，降低更换单一标识反复请求的空间。
落地时按这几步操作
- 列出重点接口：从访问日志中找请求量异常、耗时较长或能触发邮件、短信等外部操作的路径。
- 选择身份键：组合账号、会话标识或来源地址；明确代理转发时如何取得可信的客户端地址，避免直接信任任意请求头。
- 配置分层规则：分别设置个人速率、接口并发和服务总量上限。多台应用实例需要共享计数状态，或采用能协调各实例的限流组件，否则每台机器各自计数会放大实际总额度。
- 先观察再拦截：初期记录哪些请求会被限，而不立即拒绝；核对高峰和共享网络用户后，再逐步启用拦截并设置回退方案。
- 返回清晰信号：被限制时返回 HTTP 429，并在适用时提供 Retry-After，提示客户端稍后重试；客户端应采用逐步延迟和随机抖动，避免齐刷刷重试。
监控误伤与持续调整
至少观察限流命中次数、429 比例、接口延迟、服务错误率和不同身份的分布。若正常用户集中触发限制，应检查身份键是否过粗、阈值是否按峰值设置，而不是立刻放宽所有规则；若请求来自大量不同来源，则强化接口成本控制、账号验证和全局并发保护更有效。规则变更宜先小范围启用，并保留按接口关闭或调低限制的途径。
如果需要梳理应用接口保护，并同时评估网络与服务器部署条件，可把德讯电讯作为咨询选项之一；选择前应明确服务范围、运维责任和限流能力由谁配置，不能把供应商名称当作策略本身。无论自行部署还是寻求服务支持，应用层请求洪水的速率限制策略都应以实际日志和容量测试校准。
常见问题
限速后应该返回什么？
通常返回 HTTP 429；若能估计恢复时间，可附上 Retry-After。不要用成功响应伪装拒绝，以免客户端继续无效重试。
只按 IP 限制够不够？
通常不够。共享出口会让正常用户互相影响，分布式请求又可能来自许多地址；应结合账号、接口、并发及全局保护。
应该一开始就强制拦截吗？
不建议。先用观察模式统计命中对象，确认阈值不会明显影响正常峰值，再逐步启用并持续查看 429 和错误率。
归根结底，应用层请求洪水的速率限制策略要限制的是可识别的风险和资源消耗，而不是盲目追求更低的数字；分层控制、温和上线和持续监控缺一不可。
