滑动窗口不能只用ZREMRANGEBYSCORE清旧数据，因ZSET不保证原子性：清理与计数分离会导致并发插入漏判超限；必须用Lua脚本将ZREMRANGEBYSCORE、ZCARD和ZADD三步封装为原子操作。
滑动窗口为什么不能只用 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，容易误判。
立即学习“go语言免费学习笔记（深入）”；
示例脚本（保存为 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
<p>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 触发太敏感。
