内容分发场景下的限流策略选型

在内容分发和链接管理场景中，限流是保护接口、防止恶意刷量与批量爬取的基础手段。本文从实际防护需求出发，梳理四种常见做法的取舍，帮助开发者根据自身业务规模和技术栈快速选定方案。

固定窗口与滑动窗口的取舍

固定窗口在时间边界处存在突发流量穿透的问题。假设窗口为一分钟、阈值 100 次，攻击者在一分钟的最后两秒和下一分钟的前两秒各发 100 次请求，两秒内通过 200 次，但两个窗口各自计数均未超限。滑动窗口通过将时间切分为更小的粒度并持续滚动统计，能消除边界突发问题。

在链接分发场景中，固定窗口适用于对精度要求不高、流量波动平缓的后台接口，例如内容创作者的链接生成配额。滑动窗口适用于面向终端用户的分发接口，例如短链跳转、渠道投放链接的访问统计，这些场景下恶意请求往往集中在短时间爆发，固定窗口的边界穿透会直接导致统计数据失真和接口被打满。

实现上，固定窗口用一个计数器加过期时间即可，Redis 中对应 INCR + EXPIRE 的组合。滑动窗口需要用有序集合记录每次请求的时间戳，统计时剔除窗口外的旧记录。滑动窗口的内存开销和计算量都高于固定窗口，在 QPS 较高的分发接口上需要评估 Redis 的负载。

按 IP 限流 vs 按账号限流

按 IP 限流防护的重点是匿名攻击和批量爬取。内容分发平台经常面对未登录用户的批量请求，例如恶意扫描短链、批量解析渠道投放链接的真实地址。按 IP 限流能在这类请求到达业务逻辑之前将其拦截，保护后端资源。

按账号限流防护的重点是已认证用户的异常行为。内容创作者登录后批量生成链接、渠道方通过 API 高频拉取分发数据，这类请求带有合法身份，按 IP 限流无法区分同一 NAT 出口下的不同用户。按账号限流能精确控制每个实体的配额，也便于在触发限流时给出明确的提示信息。

实际落地时通常组合使用：外层按 IP 做粗粒度拦截，挡住大部分匿名攻击；内层按账号做细粒度控制，保护已认证用户的配额。两层阈值需要分别设定，IP 层阈值应远高于账号层阈值，避免同一出口下的正常用户被误伤。

单机实现与分布式实现的边界

本地计数（如进程内 ConcurrentHashMap 或 Guava RateLimiter）适用于单实例部署、对一致性要求不高的场景。例如内容管理后台的链接生成接口，每个实例独立计数，即使各实例之间存在短暂的不一致，也不会对整体业务造成明显影响。

当内容分发跨多个节点时，必须引入集中式存储。判断标准很简单：如果限流结果需要在多个实例之间共享和累计，就必须用 Redis。典型场景是面向终端用户的短链跳转接口，请求会被负载均衡分散到不同节点，如果每个节点独立计数，攻击者只需将请求分散到多个节点即可绕过限流。

Redis 实现限流时需要注意原子性。固定窗口用 Lua 脚本保证 INCR 和 EXPIRE 的原子执行，避免计数已增加但过期时间未设置的中间状态。滑动窗口用有序集合的 ZADD + ZREMRANGEBYSCORE 组合，同样需要 Lua 脚本保证原子性。在高 QPS 下，Lua 脚本的执行时间需要控制，避免阻塞 Redis 主线程。

误伤处理与降级策略

限流的核心矛盾是：阈值设低了会误伤正常用户，设高了防护效果减弱。在内容分发场景中，误伤的代价尤其高——一个正常的内容创作者在发布高峰期被限流，直接影响其内容的分发效率。

验证码是常见的误伤兜底手段。当请求触发限流阈值时，不直接返回 429，而是返回一个需要验证码验证的响应。正常用户通过验证码后即可继续访问，自动化脚本则无法通过。验证码的触发时机需要根据业务特点调整：对于短链跳转接口，首次触发时直接返回验证码；对于内容创作者的链接生成接口，可以设置更高的触发阈值，避免影响正常创作流程。

白名单机制用于保护已知的高价值实体。内容分发平台可以将合作渠道方、内部系统的 IP 或账号加入白名单，跳过限流检查。白名单需要定期清理，避免过期条目长期占用资源。

限流规则需要支持动态调整。流量模式会随业务变化而变化，例如渠道投放带来的流量高峰、恶意攻击的突发增长。将限流阈值存储在配置中心，支持运行时调整，避免每次修改都需要重新发布。调整时需要记录变更历史，便于在出现问题时快速回滚和复盘。

最后，限流触发后的降级策略需要提前设计。当 Redis 不可用时，限流逻辑应该 fail-open 还是 fail-close，取决于业务对可用性和安全性的权衡。内容分发接口通常选择 fail-open，保证用户可以正常访问内容，同时记录告警日志，在 Redis 恢复后补做统计和审计。