Redis固定窗口限流的INCR陷阱与优化方案

1. 为什么INCR不适合固定窗口计数？

在Redis的实际应用中，INCR命令常被用来实现计数器功能。但很多开发者会直接用它来实现固定时间窗口的请求限流，这其实存在几个致命缺陷。固定窗口限流的核心需求是在特定时间段内（比如1分钟）统计请求次数，超过阈值则拒绝服务。表面上看，INCR+EXPIRE的组合似乎完美契合这个场景，但魔鬼藏在细节里。

我曾在电商大促期间踩过这个坑。当时用INCR实现秒级限流，结果凌晨流量突增时系统直接崩了。事后排查发现，INCR在时间窗口切换时存在严重的临界点问题。比如设置1分钟的窗口，在00:59:59和01:00:00这两个时间点，本应属于两个窗口的请求会被错误统计到同一个窗口里，导致限流失效。

2. INCR实现固定窗口的典型问题

2.1 时间窗口漂移问题

用INCR+EXPIRE组合时，代码通常这样写：

INCR rate_limiter_key
EXPIRE rate_limiter_key 60

这里存在两个隐患：

1. 如果INCR执行后Redis崩溃，EXPIRE可能未被设置，导致key永久存在
2. 每次访问都会重置过期时间，实际时间窗口会不断向后漂移

实测发现，在QPS 1000的场景下，原本1分钟的窗口实际可能延长到61-63秒。对于需要精确时间控制的场景（如秒杀系统），这种误差完全不可接受。

2.2 性能瓶颈与原子性问题

高并发场景下，INCR操作需要配合WATCH/MULTI实现原子性：

WATCH rate_limiter_key
current = GET rate_limiter_key
if current >= threshold:
    UNWATCH
    return false
MULTI
INCR rate_limiter_key
EXPIRE rate_limiter_key 60
EXEC

这种实现方式会产生大量事务冲突。在我们的压测中，当并发超过5000时，失败率高达30%。更糟的是，WATCH会显著增加Redis CPU负载，在集群环境下问题会更严重。

3. 更优的固定窗口实现方案

3.1 Redis+Lua脚本方案

经过多次迭代，我们最终采用Lua脚本实现原子操作：

local current = redis.call('GET', KEYS[1])
if current and tonumber(current) >= tonumber(ARGV[1]) then
    return 0
end
local newVal = redis.call('INCR', KEYS[1])
if newVal == 1 then
    redis.call('EXPIRE', KEYS[1], ARGV[2])
end
return 1

这个方案解决了三个关键问题：

1. 原子性操作避免竞态条件
2. 只在第一次INCR时设置EXPIRE
3. 单次网络往返减少延迟

实测QPS可达15000+，且时间窗口精度误差小于100ms。

3.2 基于时间戳的Sorted Set方案

对于需要更精确控制的场景，可以采用ZSET存储时间戳：

ZADD rate_limiter_window NOW_TIMESTAMP NOW_TIMESTAMP
ZREMRANGEBYSCORE rate_limiter_window 0 NOW_TIMESTAMP-WINDOW_SIZE
ZCARD rate_limiter_window

虽然内存占用更高，但能实现：

• 精确的时间窗口控制
• 灵活调整窗口大小
• 避免INCR的溢出风险

4. 生产环境中的避坑指南

4.1 监控指标设置

必须监控这些关键指标：

• 限流触发频率
• Redis内存增长趋势
• Lua脚本执行耗时
• 时间窗口实际误差

我们曾遇到Lua脚本阻塞Redis的问题，后来通过拆分大脚本为多个小脚本解决。

4.2 集群环境适配

在Redis Cluster中要注意：

1. 所有限流key必须落在同一slot（使用hash tag）
2. 考虑跨节点同步延迟
3. 备选本地限流作为降级方案

某次机房网络分区时，幸亏我们实现了本地限流降级，否则整个系统都会雪崩。

4.3 性能优化技巧

• 使用pipeline批量处理限流检查
• 对非关键路径采用宽松限流
• 设置合理的默认通过阈值
• 定期清理过期key防止内存泄漏

这些技巧让我们的API网关在双11期间稳定处理了每秒20万+的限流判断。