接口被刷量如何限流防护？实战策略与核心原理全解析
目录导读
为什么接口会被刷量？常见攻击场景
接口被刷量的本质是非正常用户行为在短时间内发起远超设计容量的请求，导致资源耗尽、服务瘫痪,常见的攻击目的包括：
- 数据爬取：恶意抓取商品信息、用户数据或价格，用于不正当竞争。
- 抢票/秒杀：通过高频请求尝试抢购低价商品，破坏公平性。
- CC攻击：利用大量代理IP向API发送低成本的请求，消耗服务器连接池和数据库连接数。
- 验证码打码：通过机器识别工具绕过图形验证码，持续调用发送短信或登录接口,造成高额成本损失。
预警信号：QPS（每秒查询数）突然飙升超过近7天均值的3倍、同一IP返回大量404/500错误、CPU或内存利用率线性增长。
限流的四大核心原则与误区
原则1：拒绝是保护，容量是真相
限流不是拒绝所有请求，而是基于系统容量进行拦截，容量可通过压测获得（单机最大并发200，QPS上限5000）,超出部分直接丢弃或排队。
原则2：统计窗口必须“细化”
使用滑动窗口而非固定窗口，固定窗口（如1分钟内最多100次请求）会导致“临界突刺”：用户在每分钟的最后一秒打满100次，下一秒又打完100次,实际QPS可达200。
原则3：隔离不等于分流
简单将请求分散到多台服务器并不能解决刷量问题，攻击者同样可以分别攻击每台服务器，需要全局共享的计数器（如Redis）来统一决策。
误区：仅依赖IP白名单
大多数刷量IP为动态代理，黑名单滞后性极高，应结合令牌桶算法和用户行为特征综合判断。
实战限流方案：从单体到分布式
方案1：单机限流（适用小型应用）
- 令牌桶：固定速率（如50个/秒）放入桶中，请求消耗令牌，令牌耗尽则拒绝，适用于允许突发流量（如活动秒杀）。
- 漏桶：请求进入队列以固定速率流出，适用于平滑流量（如视频流上传）。
代码示例（简单伪代码）：
class TokenBucket:
def __init__(self, rate, capacity):
self.rate = rate # 每秒放入令牌数
self.capacity = capacity # 桶大小
self.tokens = capacity
self.last_time = time.time()
def allow(self):
now = time.time()
increase = (now - self.last_time) * self.rate
self.tokens = min(self.capacity, self.tokens + increase)
if self.tokens >= 1:
self.tokens -= 1
return True
return False
方案2：分布式限流（推荐生产环境）
使用Redis + Lua脚本实现高并发下的原子性计数,避免竞态问题。
脚本逻辑：
- 通过
INCR递增当前秒级的计数器。 - 若计数器值超过阈值，则返回拒绝。
- 设置过期时间（如2秒）自动清理。
- 配合令牌桶或滑动窗口（使用ZSET）使统计更精确。
方案3：网关级限流
在Nginx、API Gateway（如Kong、Apache APISIX）中配置限流模块,优点是无需修改业务代码。
Nginx配置示例：
limit_req_zone $binary_remote_addr zone=login:10m rate=10r/s;
location /api/login {
limit_req zone=login burst=20 nodelay;
proxy_pass http://backend;
}
解释：每个IP最多每秒10次请求,允许突发20次并立即返回。
不得不防的“反限流”手段（攻击者视角）
攻击者会尝试绕过你的限流逻辑,常见手段包括：
- 变换User-Agent：伪造不同类型的浏览器或设备标识。
- IP轮询：使用代理池切换出口IP，规避IP级限流。
- 慢速攻击：降低请求频率至限流阈值之下，但持续数小时消耗连接资源。
- 并发死锁：利用慢SQL或上传大文件导致线程阻塞,造成雪崩。
对应防御措施：
- 设备指纹：通过浏览器指纹（Canvas、WebGL、字体列表）绑定用户，即使IP变了也能识别。
- 行为验证：记录请求间隔、鼠标路径、点击热力图，异常行为直接429。
- 全局限流：在IP限流基础上，增加对全局相同参数的请求计数（同一订单号被频繁修改）。
自动化防御体系：动态限流与熔断降级
对于高流量场景，静态限流难以应对突发波动，推荐自适应限流：
- 指标采集：实时监控CPU、内存、DB连接池、QPS。
- 动态调节：当系统负荷超过80%时，自动降低限流阈值（如从100降为60）。
- 熔断降级：当错误率超过阈值（如5%），直接熔断该接口，返回降级数据（如缓存中的旧结果）。
- 依赖隔离：使用线程池隔离不同服务,避免短信接口耗尽全部连接资源。
开源工具推荐
- Guava RateLimiter：Java单机令牌桶实现。
- Resilience4j：支持熔断、限流、重试。
- Sentinel：阿里开源的流量防卫兵，支持实时监测、动态规则、控制台可视化。
常见问题 Q&A
Q1：限流之后，拒绝的请求直接丢弃吗？
A：不推荐直接丢弃，应返回HTTP 429 Too Many Requests，并附带Retry-After头部告知客户端等待秒数,同时记录请求日志以备分析。
Q2：如何在不降低用户体验的情况下限流？
A：采用排队等待策略，例如漏桶算法，对核心接口（如下单）允许请求进入队列，按固定速度处理，前端显示“排队中”，对于非核心接口（如评论）,直接返回降级响应。
Q3：限流真的能防止刷量吗？
A：限流本身不是银弹，攻击者若使用低频持续攻击，很难通过限流阻断，此时需要配合风控系统（识别恶意特征）和内容加密（如反爬虫验证码）。
Q4：为什么有时候设置了限流，数据库还是被打爆？
A：可能限流作用于API网关，但攻击者直接绕过网关（如WebSocket接口未被保护），或限流规则的优先级配置错误（如白名单未生效），建议在所有入口包括CDN、WAF、业务层同时部署。
Q5：有没有办法自动识别是刷量流量还是正常用户？
A：使用Device Fingerprint（设备指纹）+ 行为画像，例如计算用户的点击间隔分布，若80%的请求间隔小于50ms且来自不同IP，则判断为机器，还可使用“蜜罐”链接只提供给机器。
接口防刷量是一个体系化工程，需结合限流算法（令牌桶/漏桶）、架构设计（分布式/网关/熔断）、风控策略（设备指纹/行为验证）三方面构建纵深防御，从压测获取容量数据开始，逐步调整规则，并实时监控系统负荷，才能真正做到“有备无患”。
标签： 限流防护
