高频访问该如何限流防护？

wen 网络安全 2026-06-06 70

从原理到落地的完整策略

目录导读

为什么需要限流？——高频访问的真实破坏力
核心限流算法对比：计数器、滑动窗口、漏桶与令牌桶
分布式场景下的限流方案选型
实战问答：限流阈值设置与异常流量识别
最佳实践：结合缓存与降级的高可用防护体系

为什么需要限流？——高频访问的真实破坏力

在日常运维中,高频访问通常指单用户或IP在短时间内发起远超正常阈值的请求（例如每秒100次以上），这种流量可能来自：

高频访问该如何限流防护？

恶意爬虫（数据窃取、库存抢占）
业务突发热点（秒杀、促销、新闻事件）
系统故障导致的重复重试（如网关重试风暴）

如果不加防护,一个每秒处理1000次请求的API网关，被10个恶意爬虫以每秒100次访问时，就会直接击穿后端数据库连接池，导致整个服务雪崩。限流不是限制正常用户，而是保护系统不被非预期的流量压垮。

核心限流算法对比：计数器、滑动窗口、漏桶与令牌桶

1 固定窗口计数器（最容易实现，但存在突刺漏洞）

原理：以1秒为窗口，累计请求数，超过阈值则拒绝。
缺点：窗口切换时可瞬间涌入两倍阈值的请求，例如设置QPS=100，第999ms到1000ms可并发200次请求。
适用：测试环境或对精度要求极低的场景。

2 滑动窗口日志（精度高，但占用内存）

原理：记录每个请求的时间戳，在窗口内滑动剔除过期记录。
优点：避免了固定窗口的突刺问题；
缺点：需要记录所有时间戳，内存消耗随QPS线性增长。

优化方案：使用滑动时间窗口计数器，将窗口划分为多个小格子（如将1秒分成10个100ms格子），每个格子独立计数，动态滑动时只需清理最老的格子。

3 漏桶算法（强制平滑流量，但无法应对突发流量）

原理：请求先进入漏桶，以固定速率流出（类似网络流量整形），桶满则拒绝。
优点：彻底平滑流量，适合数据库写操作等不允许突发的场景；
缺点：无法处理短时间内需要快速响应的突发请求（如秒杀首单）。

4 令牌桶算法（兼顾平滑与突发，生产环境首选）

原理：以固定速率生成令牌存入桶中（最大容量固定），请求需获取令牌才能执行，桶空则等待或拒绝。
优点：允许空闲时积累令牌，支持突发流量；
缺点：需要维护令牌生成线程（可用分布式缓存实现）。

实际场景：阿里云API网关、Nginx官方限流模块均基于令牌桶实现。

分布式场景下的限流方案选型

单机限流在多节点部署时出现误差：假设单台机器QPS限制为100，6台机器整体可承受600QPS，但恶意请求可能集中攻击其中一台，导致该机器崩溃。

基于Redis + Lua脚本的分布式限流

实现步骤：
1. 使用Redis的INCR+EXPIRE在1秒内记录请求数；
2. 调用Lua脚本判断当前计数是否超过阈值（原子操作，避免竞态）；
3. 超过则返回429状态码（Too Many Requests）。
优点：实现简单，低延迟（单次Redis操作耗时<1ms）；
缺点：依赖Redis高可用，Redis故障则限流失效。

Lua脚本核心示例（简化）：

local key = KEYS[1] -- “对应限流key”
local limit = tonumber(ARGV[1])
local current = redis.call('INCR', key)
if current == 1 then
    redis.call('EXPIRE', key, 1)
end
if current > limit then
    return 0 -- 拒绝
end
return 1 -- 允许

服务网格（如Istio Envoy Filter）

原理：在Sidecar代理层面进行全局限流，基于请求的Header（如User-ID）限流；
优点：对业务代码零侵入，统一控制；
缺点：运维复杂度较高，适合微服务化成熟的企业。

网关层限流（Kong/APISIX/Nginx）

配置示例：Nginx的limit_req_zone模块：

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

注意事项：需同时限制单IP和总请求数，避免单个IP崩溃后其他IP仍正常访问。

实战问答：限流阈值设置与异常流量识别

问题1：如何确定系统真实的QPS阈值？

不要依赖猜测,先通过压测工具（如Locust或wrk）逐步加压，记录数据库连接池、CPU、内存的临界点，例如压测发现数据库连接池在500QPS时开始排队，则预留30%冗余，将限流阈值设为350QPS。

问题2：高频访问与正常突发流量如何区分？

通过多维特征判断：

请求频率：正常用户不可能连续10秒每秒发50次请求（除非使用自动化工具）；

来源IP分散度：恶意爬虫通常使用IP池，分析IP的ASN（运营商）分布是否集中在某个云数据中心；

User-Agent：非浏览器UA（如Python-requests）直接判定为爬虫；

业务行为：同一商品ID在1秒内被同一IP轮询价格超过30次，判定为爬虫。

问题3：限流生效后如何处理被拒绝的请求？

返回HTTP 429状态码，并携带Retry-After头部（建议值=窗口长度，如1秒），前端收到429后应暂停重试，可告知用户“请稍后再试”。

问题4：限流是否会误伤正常用户？

会！因此建议实施用户分级限流：

注册用户：VIP用户阈值是普通用户的5倍；

API Key维度：商家API与内部API分开限流；

动态调整：当系统负载降低时自动提升阈值（结合CPU/内存反馈）。

最佳实践：结合缓存与降级的高可用防护体系

单一限流无法应对所有场景,需构建“协防”架构：

第一步：前端CDN防护

使用CDN节点的WAF（Web应用防火墙）对高频IP进行封禁，阻断恶意流量进入源站；
对动态API使用CDN的边缘计算进行限流（例如Cloudflare Workers）。

第二步：网关层限流+熔断

在入口网关（如Nginx）根据Header/Path进行细粒度限流，同时启用熔断（当错误率>20%时自动熔断30秒）；
对限流失败请求返回静态降级页面（示例：(function(){window.location.href=‘https://你的域名/429.html’})();）。

第三步：应用层熔断+本地缓存

使用Resilience4j或Sentinel在应用内实现熔断（当接口超时率>50%时开启）；
对热点数据（如商品详情）设置本地缓存（如Caffeine），减少数据库查询压力。

第四步：数据库列队限流

数据库连接池限制最大200个连接,多出来的请求自动排队或返回失败；
使用SQL限流（如MySQL的MAX_EXECUTION_TIME）防止慢SQL拖垮数据库。

高频访问限流的核心三要素是：算法选型（推荐令牌桶）、分布式一致性（Redis+Lua/网关）、分级防护策略（用户+IP+API Key），没有100%完美的限流方案，关键在于根据业务特点选择“够用且可维护”的解决方案，并定期通过压测验证限流阈值是否合理。

附：完整的限流规则模板已托管在技术博客的常见框架库中（如Spring Cloud Gateway的RequestRateLimiter示例），可直接修改后集成至现有项目。