视频CDN承载的流量往往由多种API组成：获取播放列表、请求分片、上传视频、查询状态等。如果使用全局统一的Rate Limit，那么任何一个接口被刷都会导致整个域名进入限流状态，正常观看也会被阻断。基于API路径的精细限流把控制粒度下沉到每个URL模式，让不同业务接口拥有自己的容量上限，从而在防止滥用的同时保留核心可用性。
为什么需要API路径级的限流
视频CDN的请求类型高度异构。播放列表接口可能每分钟只被调用几次，而分片下载接口每秒要承载数百次请求。如果按照同一个QPS阈值来限制，设置过高起不到保护作用，设置过低又会把正常的播放列表请求误杀掉。更麻烦的是，恶意刷量往往集中在少数的重资源接口，比如不断请求同一个大分片，而其他路径并未受到攻击。路径级限流能够把保护范围精确到某个URL模式，只针对异常路径进行压制，其他路径照常服务。
从成本角度看，CDN回源流量和边缘计算资源都直接和请求路径相关。对播放列表等低频但关键接口做严格限流，可以防止脚本反复拉取元数据导致源站压力增大；对分片下载接口设置宽松但非无限的阈值，可以避免单个客户端把带宽打满。这种策略还能帮助运营团队做容量规划，因为不同路径的限流数据直接反映业务模型中的热点和瓶颈。
另外，API路径限流还便于和业务权限结合。例如上传接口只允许已认证用户调用，可以通过路径前缀进行识别，对未携带合法签名的请求直接限制到极低配额。相比仅仅依靠IP或用户ID，路径本身提供了更稳定的分组维度，因为IP可能被共享或通过代理变化，而URL结构在业务迭代中通常保持不变。
路径限流的实现思路与关键技术
实现路径级限流的第一步是定义路径规则。通常采用前缀匹配或正则匹配，将`/video/playlist/`、`/video/segment/`、`/api/upload/`等路径映射到不同的限流桶。前缀匹配性能较好，适合边缘节点上的轻量级判断；正则匹配更灵活，但编译和匹配开销较高，需要控制规则数量。配置文件中可以让运维人员为每个路径模式指定速率、突发容量和惩罚时长。
限流算法方面，令牌桶和滑动窗口是两种主流选择。令牌桶允许一定程度的突发流量，适合视频分片这种可能出现短暂集中的场景；滑动窗口则能更精确地限制单位时间内的请求总数，对防止平均速率超限更有效。在实际部署中，很多系统采用Redis作为全局计数器，通过Lua脚本原子性地执行递增和过期操作。Redis的写入性能足够支撑CDN边缘节点的高并发查询，但也要考虑网络延迟，可以在边缘节点本地缓存一段时间的配额状态。
另一个关键点是路径归一化。同一个API可能因为尾部斜杠、大小写、查询参数顺序不同而被识别为不同路径。例如`/video/playlist/`和`/video/playlist`如果被视为两个规则，就会产生限流漏洞。因此在匹配之前需要对URI进行标准化：统一小写、去除多余的斜杠、剥离查询字符串，必要时对路径参数进行抽象，比如把`/video/12345/segment/1`归一化成`/video/{id}/segment/{seq}`模式。归一化做得好，规则数量会大幅减少，命中率也会提高。
基于Nginx与Lua的落地示例
在实际的CDN边缘节点上，Nginx配合Lua模块是常见的路径限流方案。下面给出一个精简的配置片段，展示如何对不同路径分配不同的限流参数。该配置使用了Nginx自带的`limit_req`指令，通过不同的`limit_req_zone`来区分路径组。
# 定义路径对应的共享内存区域
limit_req_zone $playlist_key zone=playlist_zone:10m rate=5r/s;
limit_req_zone $segment_key zone=segment_zone:100m rate=200r/s;
server {
listen 80;
server_name cdn.ipipp.com;
# 播放列表路径使用严格限流
location /video/playlist/ {
set $playlist_key $uri;
limit_req zone=playlist_zone burst=10 nodelay;
proxy_pass http://origin;
}
# 分片路径使用较高限额
location /video/segment/ {
set $segment_key $uri;
limit_req zone=segment_zone burst=500 nodelay;
proxy_pass http://origin;
}
}
上述配置中，`$playlist_key`和`$segment_key`作为`limit_req_zone`的键，可以直接使用URI变量。但需要注意，Nginx的`limit_req`是基于共享内存的本地限流，在多节点部署时只能限制单机。如果需要全局统一限流，则可以借助Lua读取Redis实现分布式计数。下面是一个Lua片段，利用Redis的原子操作实现基于路径的滑动窗口限流。
local redis = require "resty.redis"
local red = redis:new()
red:set_timeout(1000)
local ok, err = red:connect("127.0.0.1", 6379)
if not ok then
ngx.exit(500)
end
-- 归一化URI，去除查询字符串和多余斜杠
local uri = ngx.var.uri:lower()
uri = uri:gsub("/+", "/")
local key = "rate:path:" .. uri
local limit = 100
local window = 1
-- 使用ZSET实现滑动窗口
local now = ngx.now()
local window_start = now - window
local count, err = red:zcount(key, window_start, now)
if count and count >= limit then
ngx.exit(429)
end
red:zadd(key, now, now .. ":" .. ngx.var.request_id)
red:zremrangebyscore(key, 0, window_start)
red:expire(key, window * 2)
这段Lua代码演示了滑动窗口的核心逻辑：使用Redis有序集合存储每个请求的时间戳，通过`zcount`统计当前窗口内的请求数，超限则返回429状态码。时间戳作为score和member的一部分，保证成员唯一。需要注意的是，实际生产环境需要处理Redis连接池、超时降级以及集群模式下的键分布问题。如果Redis不可用，通常可以选择放行或者降级为本地限流，避免因依赖故障导致服务中断。
路径匹配规则与常见误区
路径匹配的准确性直接影响限流效果。最常见的错误是把整个URI包括查询字符串都作为匹配目标，这会导致同样的API因为不同的签名参数、分页参数而被分散到不同键中，限流形同虚设。正确做法是只取路径部分，必要时提取路径中的动态片段进行模式化。例如使用正则`/video/(\d+)/segment/`将数字ID替换为占位符，这样所有视频的分片请求都归入同一类规则。
另一个容易忽视的问题是路径大小写和尾部斜杠。CDN节点通常对URL大小写敏感，但业务侧可能并不区分。如果限流规则只写了小写路径，攻击者使用大写路径就能绕过限制。因此必须在限流模块内部做统一归一化，同时保证上游业务对大小写的处理逻辑一致。尾部斜杠的处理也要明确：`/api/upload`和`/api/upload/`应该视为同一个路径，否则就可能出现双倍配额。
缓存穿透也可能影响路径限流的精度。有些CDN会缓存限流决策结果，但缓存时间过长会导致规则更新不及时。建议在本地缓存中只缓存短时间内的计数状态，或者使用事件推送机制通知节点更新规则。对于需要快速下发的紧急封禁，可以在边缘节点预留一个黑名单接口，通过控制平面直接注入路径前缀，不经过Redis查询直接拦截。
生产环境中的调优建议
在真实视频CDN场景中，路径限流的参数需要根据业务数据持续调整。可以先从日志中统计每个路径的QPS分布，找出P95和P99延迟对应的请求量，再设定初始限流值，并逐步收紧或放宽。监控指标要覆盖每个路径分组的限流触发次数、被拒绝请求的比例以及正常请求的通过率，避免限流阈值错误导致用户投诉。
性能方面，如果使用Redis做远程计数，平均每个请求增加1到3毫秒的延迟，对于视频分片这种大流量场景可能不可接受。优化手段包括：在边缘节点使用本地共享内存计数器进行第一层限流，再定期向Redis同步聚合；或者采用令牌桶的本地预分配模式，从Redis一次性领取一批令牌，在本地消耗完后再申请，降低远程调用频率。对于对延迟极其敏感的路径，可以只使用本地限流，接受多节点间的限流误差。
最后，路径级限流不应该孤立使用。它需要与IP限流、用户级限流、设备指纹识别等多种策略组合，才能构建完整的防护体系。API路径提供了业务维度的分组，IP提供了客户端维度的抑制，用户身份则能实现更公平的配额分配。三者结合后，可以在保护CDN资源的同时，最大程度保留合法用户的访问体验。
视频CDNRate LimitAPI路径限流修改时间：2026-10-06 22:33:23