网站遭遇异常请求时的限流策略，关键不在于把所有请求一概挡住，而是尽早识别超出处理能力的流量，并让正常访问仍有机会完成。规则放在应用已经执行大量计算之后，省下的资源有限；部署在入口或服务调用前，才更可能稳住响应。
限流能解决什么，不能解决什么
当短时间内的请求超过应用、数据库或外部服务的承载能力，排队会变长，响应时间随之上升，甚至拖累正常用户。限流可限制进入系统的请求量或并发任务数，减少无效计算、连接占用和重复查询。
不过，限流不是扩容的替代品，也不能单独处理所有攻击。若请求来自大量分散来源，单按来源地址计数可能拦不住整体洪峰；若规则设得过紧，也会误伤共享网络中的真实访客。网站遭遇异常请求时的限流策略应与缓存、容量规划及异常告警配合使用。
先选规则：按什么限、用什么算法
按资源和访问身份组合
先区分静态内容、普通读取接口和高成本操作。公开内容页面通常可承受更宽松的额度；会触发数据库写入或复杂计算的接口，应单独设置较低阈值。可组合账户、会话、来源地址和接口路径判断，避免只依赖单一维度。若经过代理转发，需确认服务端读取的是可信代理传递的来源信息，不能直接信任访客自行提交的字段。
令牌桶与并发上限各有侧重
令牌桶允许一定突发流量，适合用户操作并非匀速发生的场景；持续超额时，令牌耗尽后请求会被拒绝或延迟。漏桶更强调平稳处理速率，适合希望控制下游调用节奏的任务。并发上限限制同时执行的任务数，对单次耗时长、会占用数据库连接的操作尤其有用，但它不等同于每秒请求额度。实际可组合使用，而非只挑一种。
把阈值变成可执行规则
- 记录基线：按接口观察请求速率、响应时间、错误比例、CPU和数据库连接数，覆盖日常高峰与低谷。没有基线时，先以监控和日志识别异常，不要直接部署严格拦截。
- 估算可用容量：查看服务在目标响应时间内能承受的请求量，并为正常波动留余量。作为初步验证，交互式接口可从每个会话每秒数次、允许少量突发开始测试；具体数值必须根据接口耗时、缓存命中率和后端容量校准，不适用于所有网站。
- 在昂贵操作前执行：可在反向代理、应用中间件或服务网关判断额度，尽量避免请求先完成数据库查询才被拒绝。跨多台应用实例统一计数时，可用Redis等共享存储；需评估其延迟、故障处理及计数键过期策略。
- 先观察，再逐步拦截：先记录哪些请求会触发规则，再对少量流量启用限制，检查正常用户是否被误判。超过额度时返回HTTP 429，并提供清晰的重试提示；对重要操作，还应保留人工排查和规则回退路径。
- 持续校准：对照限流命中数、正常请求成功率、响应时间和资源使用。若命中增加但资源没有改善，可能是规则位置太晚、被限接口不够关键，或压力来自另一条链路。
可靠性细节决定限流是否有效
多实例部署时，各节点各自计数可能让总额度随实例数放大；共享计数更一致，但会增加对计数服务的依赖。需要明确计数服务不可用时是暂时放行还是保守拒绝：前者可降低误伤风险，后者更能保护高成本操作，选择应按业务影响决定。
对突发流量，缓存可减少重复读取；对持续超载，可用熔断暂时停止调用已经异常的下游服务，避免排队继续扩散。网站遭遇异常请求时的限流策略是否有效，应看正常访问是否保持稳定、后端资源是否回落，而不是只看拦截数量。
常见问题
限流后响应一定会变快吗？
不一定。只有在瓶颈资源前拦截超额请求，或限制住占用资源的并发任务，才更可能改善正常请求响应；若瓶颈在网络、存储或其他服务，还需针对性处理。
只按来源地址限制可以吗？
通常不够。共享网络可能让多个正常用户使用同一出口，分布式请求也可能来自大量地址。应结合账户、会话、接口和全局容量设置规则。
如何减少误伤？
先采集基线并观察命中记录，按接口区分额度，逐步灰度；同时提供明确的拒绝提示，并监控正常请求的失败变化。
限流和熔断有什么区别？
限流控制进入系统或某接口的请求数量；熔断则在下游服务异常时暂时停止调用，重点是避免故障扩散。两者解决的问题不同，可以配合。
归根结底，网站遭遇异常请求时的限流策略应从容量和真实流量出发，先保护最容易被耗尽的资源，再通过监控修正阈值。规则适度、位置靠前并持续校准，才有机会兼顾响应稳定与资源节省。
