配置限流，第一步不是填一个“每分钟最多多少次”，而是弄清哪些请求占用资源、哪些访问节奏属于正常。处理网站遭遇异常请求时的限流策略，可以按路径梳理、设定基线、选择规则、灰度验证、持续调整五步进行。
1. 先按请求路径区分风险
同一网站里的请求成本并不相同。公开商品目录的读取通常较轻，发送短信验证码、提交注册表单则可能消耗外部服务额度；登录入口还需要关注连续猜测密码的风险。把所有路径套用一个上限，容易一边放过高成本请求，一边限制正常浏览。
先列出对用户重要、且可能被反复调用的入口，标明请求方法、是否需要登录、单次处理成本和失败影响。再决定按账户、会话、来源地址或具体路径计数。登录限制通常需要兼顾账户与来源，避免攻击者轮换来源绕过，也避免多人共用网络时被一个来源额度误伤。
2. 用实际流量建立基线
查看服务日志和监控中的请求量、响应时间、错误比例及资源占用，按路径和时段对比。若访问随工作日、活动时段或内容更新明显变化，应覆盖这些周期再定规则；只有短时间观察，可能把正常高峰当成异常。
可以先用“每个计数对象在一段时间内的请求数”做初步分析，并区分成功请求与重复失败请求。没有历史数据时，先采用保守额度、记录被限制的请求，再根据误拦和资源压力调整，不要把单一经验数字当成通用标准。
3. 选择计数方式并写清限额
固定窗口还是滑动窗口
固定窗口实现简单，例如按每分钟统计，但窗口切换前后可能出现短时集中请求。滑动窗口能更平滑地限制一段连续时间内的请求，代价是统计逻辑通常更复杂。若还希望允许短暂突发、同时约束长期平均速度，可考虑令牌桶；具体采用哪种方式，要看现有网关或应用组件是否支持，以及突发流量是否能被后端承受。
限额应写明对象、路径、时间范围和超限动作。例如，对注册接口按账户限制短时间内的提交次数，对公开读取接口按会话设置较宽松的额度。初始值可通过线上观测或压测确定；压测结果只适用于相应配置和负载，不等于真实用户的固定行为。
4. 设计超限响应和例外
超限时通常返回429状态码，并给出简短、可理解的提示；客户端应减少重试频率，而不是立刻循环重发。对验证码发送、付款确认等操作，还要确认重复提交是否会造成重复副作用，必要时配合幂等处理。
例外规则要少且可审计。内部健康检查、受控的监控请求可单独配置，但不要因为方便就长期放宽整个站点。若规则可能影响合作方或自动化客户端，应提前核对其调用节奏，并提供明确的错误说明。
5. 小范围启用后再逐步调整
- 先在日志或观察模式中记录“哪些请求会触发限流”，暂不拦截，检查误判。
- 选少量路径或一部分流量启用规则，观察限制次数、正常请求失败率、响应延迟和后端负载。
- 出现误伤时，先确认计数对象、共享网络和业务高峰，再调整额度或拆分规则；出现资源压力却未触发时，检查是否路径覆盖不足。
- 记录规则负责人、变更时间和回退方法。业务入口或访问模式改变后，重新核对阈值。
这样做能让网站遭遇异常请求时的限流策略从可观察、可解释的规则开始，而不是上线后才发现正常用户被挡在门外。上线后持续复核，比一次设定后长期不管更可靠。
常见问题
限流应该放在网关还是应用里？
网关适合统一处理大量入口；应用层更了解账户和业务状态。两者可分工，但要避免重复计数造成额度意外变严。
应该按来源地址还是账户限流？
取决于入口。公开读取可按来源或会话控制；登录、验证码等入口宜结合账户维度，降低轮换来源绕过的风险。
所有超限请求都应直接拒绝吗？
不一定。安全敏感操作通常应拒绝；可延迟处理的任务可进入排队机制。应根据操作是否可等待、是否有副作用来决定。
多久复查一次规则？
没有适用于所有网站的固定周期。上线初期应密切查看指标；遇到流量结构、业务入口或后端容量变化时，应及时复核。
