Golang 实现 Redis 滑动窗口统计方法

本文深入剖析了在 Go 语言中使用 Redis 实现高并发、高精度滑动窗口限流的关键陷阱与最佳实践：指出仅依赖 ZREMRANGEBYSCORE 清理旧数据会导致原子性缺失、统计失真和漏判风险，强调必须通过 Lua 脚本将 ZADD、ZREMRANGEBYSCORE 和 ZCARD 封装为不可分割的原子操作；同时详解 go-redis 客户端调用 Lua 的正确姿势（参数映射、类型安全、返回值解析）、内存优化技巧（score 与 member 均设为时间戳）、以及应对极端并发的双计数器兜底策略（ZSET 滑动窗口 + INCR/EXPIRE 分钟级 fallback），辅以可落地的代码示例和避坑指南，助你构建真正可靠、高效、可观测的限流系统。

滑动窗口为什么不能只用 ZSET 的 ZREMRANGEBYSCORE 清理旧数据

因为 Redis 的 ZSET 本身不保证原子性滑动——ZADD 和 ZREMRANGEBYSCORE 是两个独立命令，中间可能插入其他请求，导致窗口内数据短暂膨胀或漏统计。更关键的是：如果清理操作失败（比如网络中断、Redis 拒绝写入），旧数据会残留，后续统计就失真。

真正可靠的滑动窗口必须把「添加新条目 + 清理过期条目」封装成一个原子动作。Go 客户端直接调用两个命令做不到这点，得靠 Lua 脚本。

实操建议：

• 写一个 Lua 脚本，接收窗口时长（如 60 秒）、当前时间戳（unix timestamp）、key 前缀，然后在脚本里完成 ZADD + ZREMRANGEBYSCORE + ZCARD 三步
• 用 redis.Script.Load().Run() 执行，确保原子性
• 不要把时间戳生成逻辑放在 Lua 里（redis.call('TIME') 返回的是秒+微秒，精度高但跨节点可能不一致），统一由 Go 传入 time.Now().Unix()

如何用 go-redis 正确加载并执行滑动窗口 Lua 脚本

很多人直接拼接字符串传 Lua，结果遇到转义、参数类型错位、返回值解析错误。核心是：Lua 脚本里的 KEYS[1] 对应 Go 调用时的第 1 个 key 参数，ARGV[i] 对应第 i 个 interface{} 参数，且 go-redis 会自动把 Go 的 int64、string 映射为 Lua 的 number/string，但 nil 会变成 false，容易误判。

示例脚本（保存为 sliding_window.lua）：

local key = KEYS[1]
local now = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local score = now
local min_score = now - window
redis.call('ZADD', key, score, score)
redis.call('ZREMRANGEBYSCORE', key, '-inf', min_score - 1)
return redis.call('ZCARD', key)

Go 端调用方式：

script := redis.NewScript(luaContent)
count, err := script.Run(ctx, rdb, []string{"rate:login:192.168.1.1"}, time.Now().Unix(), int64(60)).Int64()

注意点：

• KEYS 必须是非空字符串切片，哪怕只有一个 key；ARGV 中的 int64 会被正确传入 Lua，不用转 string
• 返回值用 .Int64() 获取，不是 .Result() —— 后者返回 (interface{}, error)，需手动类型断言
• 如果脚本里用了 redis.call('EXISTS', ...) 判断 key 是否存在，记得在 Go 里用 .Bool() 接收

ZSET 成员值该存什么：时间戳就够了，别存冗余字段

常见误区是存 ZADD rate:login:ip 1672531200 "1672531200:uuid4" 这种带结构的字符串，以为方便 debug 或扩展。其实完全没必要——滑动窗口只关心数量，不关心具体哪次请求；而且成员值在 ZCARD 统计时根本没用，纯属浪费内存和序列化开销。

正确做法就是让 score 和 member 都等于当前时间戳：

ZADD rate:login:192.168.1.1 1672531200 1672531200

这样做的好处：

• 节省约 40% 内存（避免重复存储时间戳+额外字符串）
• 避免 member 字符串过长导致 ZADD 命令变慢（Redis 对大 value 有性能惩罚）
• 万一要查具体记录（比如审计），直接用 ZRANGE rate:login:192.168.1.1 -10 -1 WITHSCORES 就能拿到最近 10 次的时间戳

并发请求下怎么防止误限流：用 INCR + EXPIRE 做 fallback 更可靠

单纯依赖 ZSET 滑动窗口，在极端并发场景（比如瞬间 1000 请求打到同一 IP）下，Lua 脚本虽原子，但多个连接同时执行仍可能因网络延迟导致“看似同时”的请求被算进同一个窗口，造成临界点抖动。这时候需要一层轻量兜底。

推荐组合策略：

• 主逻辑走 ZSET 滑动窗口（精度高、支持任意窗口长度）
• 同时用 INCR login:192.168.1.1:minute + EXPIRE ... 60 做分钟级粗粒度计数（利用 Redis 的 INCR 原子性和 EXPIRE 自动清理）
• 只要任一计数器超限，立即拒绝请求

这种双计数器模式成本极低（INCR 是 O(1)），又能覆盖 Lua 脚本执行间隙的盲区。真正的难点不在实现，而在监控——你得同时看两个指标：ZCARD 结果和 INCR 返回值，否则无法定位到底是滑动窗口漏了，还是 fallback 触发太敏感。

本篇关于《Golang 实现 Redis 滑动窗口统计方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！