Redis滑动窗口算法实现精准实时统计，解决高并发场景下数据延迟与内存溢出问题

使用Redis的Sorted Set数据结构，通过ZADD添加带时间戳的成员并用ZREMRANGEBYSCORE清理旧数据，结合EXPIRE设置过期时间，即可实现滑动窗口算法，精准统计单位时间内的事件次数，有效应对高并发下的延迟与内存问题。

什么是滑动窗口算法？

简单来说，滑动窗口算法就像是一个会移动的时间框。比如，你想统计一分钟内有多少人访问了你的网站。传统的做法可能是每分钟清零一次计数器，但在每分钟交接的那几秒，数据可能不准确。滑动窗口算法则不同，它始终统计的是“当前时间往前推一分钟”这个不断滑动的窗口内的数据。这样，每一秒你都能得到过去一分钟的精确访问量，没有时间盲区。

为什么用Redis来实现？

在高并发场景下，比如双十一抢购、明星直播互动，每秒可能有成千上万的请求。如果用数据库直接记录每次请求，数据库很快就会被压垮，导致响应延迟，数据堆积。Redis是内存数据库，速度极快，天生适合处理这种高频读写。但如果不加控制，一直往Redis里存数据，内存也会爆满。滑动窗口算法正好解决了这个问题，它只保留时间窗口内的数据，旧数据自动清理，完美平衡了实时性和内存消耗。

一步步用Redis实现滑动窗口

我们以统计用户一分钟内发送短信的次数为例，防止短信轰炸。

第一步：准备一个Redis的有序集合（Sorted Set）。集合的key可以像这样："rate_limit:sms:用户手机号"。有序集合的每个成员需要一个分数（score），我们用当前时间的时间戳（比如毫秒数）作为分数。

第二步：当用户发送短信时，执行一个Redis命令。用ZADD命令，把当前时间戳作为成员和分数，添加到这个有序集合里。因为成员不能重复，我们可以把“时间戳+一个随机数”作为成员，确保唯一。

第三步：关键的一步，立即清理窗口外的旧数据。用ZREMRANGEBYSCORE命令，删除分数小于“当前时间戳 - 60000”（一分钟是60000毫秒）的所有成员。这样，集合里永远只保存最近一分钟的数据。

第四步：统计窗口内的数量。用ZCARD命令，直接获取当前有序集合的成员总数，这就是过去一分钟内该用户发送短信的次数。

第五步：设置过期时间。为了避免用户长时间不操作后残留无用数据，用EXPIRE命令为这个key设置一个比窗口稍长的过期时间，比如70秒。

整个过程可以用一条Redis流水线（pipeline）打包这些命令，一次性发送给Redis执行，速度更快。

实际应用中的小技巧

1. 精度选择：根据业务需要，可以选择秒级、毫秒级的时间戳作为分数。毫秒级更精确，但数据量可能稍大。

2. 内存优化：如果单个事件不需要存储额外信息，成员（member）可以尽量简单，比如直接用时间戳字符串。

3. 分布式支持：Redis本身是单线程服务，这个算法天然支持分布式系统下的统计，所有服务实例都操作同一个Redis，计数是完全准确的。

4. 多维度统计：Key的设计可以很灵活。比如“rate_limit:api:接口路径:用户IP”，可以同时按接口和IP进行限流统计。

FAQ

问：滑动窗口算法和固定时间窗口（比如每分钟一个计数器）有什么区别？
答：固定窗口在窗口切换的瞬间，比如从第59秒到第61秒，计数会突然清零再开始，可能导致在交接处放过两倍于限制的请求（例如，59秒时来了9个请求，61秒初又来了9个，在一分钟限制10次的规则下，这两秒内的18个请求都不会被拦截）。滑动窗口则平滑移动，任何一秒看到的都是前60秒的精确总数，没有这个漏洞。

问：如果时间窗口很长，比如要统计24小时的数据，Redis内存会不会不够用？
答：如果每个事件都记录，窗口越长数据越多。对于超长窗口的统计，可以考虑分层聚合或采样。例如，统计24小时数据，可以同时维护多个不同精度的窗口：一个精确到分钟的滑动窗口统计最近一小时，一个按小时聚合的滚动计数器统计剩余23小时，两者结果相加。这样可以平衡精度和内存消耗。

问：这个算法能用来做什么？
答：用途非常广泛。除了提到的接口限流、防短信轰炸，还可以用于实时监控系统（如QPS、错误率）、用户行为分析（如最近10分钟点击次数）、热门内容排行榜（如最近一小时点赞数）等任何需要“单位时间内”统计的场景。

引用来源：该实现思路基于Redis官方文档中Sorted Set数据结构的应用，并结合了常见的限流算法实践，在众多互联网公司的生产环境中得到验证。