Web应用请求速率限制方法：额度、算法与上线步骤

Web应用请求速率限制方法没有一组适用于所有服务的固定数字。稳妥的做法是先区分请求类型，再结合正常流量、后端承载能力和用户操作节奏设定额度，并通过监控逐步调整。限速目标不是单纯拦住更多请求，而是在保护服务的同时尽量不误伤正常用户。

先确定限制对象和计数口径

不要只给整个站点套一个统一上限。公开内容读取、登录验证、搜索查询和文件处理的计算成本、正常调用频率都不同，应分别制定规则。比如，读取缓存中的商品详情通常较轻；登录验证涉及凭据校验，搜索或图片处理则可能占用较多后端资源。若它们共用同一额度，轻量请求可能挤占高成本操作的保护空间。

计数键也要按场景选。已登录用户可按账号或 API 密钥计数；未登录请求可使用客户端地址等信号，但共享网络可能让多名用户共用同一地址，单独依赖它容易误限。较稳妥的方式是组合身份与请求类别，并设置全局保护阈值，防止多个客户端同时访问压垮服务。

令牌桶以固定速度补充额度，桶内可暂存一定令牌。用户短时间连续操作时，可消耗积累的额度；持续超额后则被限制。它适合存在合理突发的交互请求。配置时分别设定补充速率和桶容量：前者约束长期平均速度，后者控制短时峰值。不要把桶容量设置得过大，否则突发仍可能把后端打满。

滑动窗口按最近一段时间统计请求，限制效果比简单的固定分钟窗口更平滑，但计数实现和存储开销可能更高。固定窗口实现简单，却可能在两个窗口交界处放行接近双倍额度。若服务更关注同时执行的任务数量，而不是每秒请求数，则应另设并发限制；它限制的是正在处理的工作，不等同于请求速率。

记录基线：按路由统计正常时段和高峰时段的请求频率、成功率、响应时间及后端资源使用情况。按用户或客户端分组观察，避免总体平均值掩盖少数高频正常用户。
估算初始额度：以正常流量分布和服务可承受能力为依据，先给额度留出余量。作为试运行起点，普通交互接口可测试每客户端每秒数次到十余次的范围，高成本操作可从每秒约一次或更低开始；这只是待验证的配置区间，不是通用标准，真实额度取决于计算成本、缓存命中和部署规模。
先观察再拦截：先记录哪些请求会触发规则，不立即拒绝；确认规则不会集中命中正常用户后，再逐步启用。观察周期应覆盖业务高峰和常见批量任务，具体时长依流量周期而定。
设置清晰反馈：超过额度时返回合适的限流响应，例如 429，并在条件允许时提供建议重试时间。客户端应采用退避重试，而不是立即循环重发；否则限速本身可能引发更多请求。
验证并回退：检查被限请求比例、正常用户失败情况、队列长度和响应延迟。若误拦截增加，先调整计数键、额度或例外条件，并保留配置变更记录，便于恢复到上一版本。

应用运行在多个实例上时，若每个实例只在本地计数，同一用户的额度可能被分散到多个实例，实际放行量高于预期。可使用共享计数存储，或由统一入口执行规则。共享存储的原子更新、网络延迟和故障行为都要纳入设计；若存储不可用，应明确选择暂时放行还是严格限制，并评估两者对业务可用性和资源保护的影响。

Web应用请求速率限制方法应当随流量和业务成本调整，而不是上线后固定不动。至少定期复核高频路由、误限情况、共享计数状态与客户端重试行为；每次修改都应可追踪、可回退。

登录后优先按账号或密钥；匿名访问可结合地址和请求类型。共享网络环境下，不宜只靠地址限速。

通常先短暂拒绝超额请求并返回重试提示，不必直接长期封禁。持续异常行为可再配合更严格的规则。

不建议。请求成本和正常频率差别较大时，应按路由类别分别设置，并保留整体资源保护上限。

明确返回可重试时间，并让客户端逐步延长重试间隔、加入随机等待，避免多个客户端同时再次请求。