滑动窗口限流必须用Redis的ZSET而非INCR+EXPIRE，因后者仅支持固定窗口，无法防止“窗口边缘刷量”；ZSET通过毫秒级时间戳实现精确滑动统计，并需Lua脚本原子执行ZREMRANGEBYSCORE、ZCOUNT和ZADD。
滑动窗口限流为什么必须用 Redis 的 ZSET 而不是 INCR + 过期时间
因为单靠 INCR 和 EXPIRE 只能做固定窗口，无法应对“窗口边缘刷量”——比如用户在第 59 秒发 5 条，第 60 秒又发 5 条，两个窗口各算 5 条，实际 2 秒内就触发了 10 次请求。ZSET 可以按时间戳精确存每条请求，再用 ZRANGEBYSCORE 查过去 60 秒内所有记录，真正实现滑动效果。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
ZADD写入时用毫秒级时间戳（System.currentTimeMillis()）作 score，手机号或 IP+手机号拼接作 member - 每次限流检查前先
ZREMRANGEBYSCORE key -inf (now-60000)清过期项，避免集合膨胀 - 别用
ZCARD算总数——它不区分时间范围，必须用ZCOUNT key (now-60000) +inf或ZRANGEBYSCORE ... WITHSCORES LIMIT 0 1配合数量判断 - 注意 Redis 版本：4.0+ 才支持
ZREMRANGEBYSCORE的(开区间语法，低版本得用ZREMRANGEBYSCORE key -inf [now-60001]
Java 里怎么安全地组合 ZADD、ZCOUNT 和 ZREMRANGEBYSCORE
不能分开调三次命令——中间可能被其他线程/实例插入数据，导致误判。必须用 Lua 脚本原子执行，否则限流就形同虚设。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 脚本里先
ZREMRANGEBYSCORE清旧数据，再ZCOUNT查当前窗口内数量，最后只在未超限时ZADD新记录 - 返回值统一设计为：-1 表示超限，0 表示通过且无新增（比如刚好卡在边界），1 表示通过并已记录
- Spring Data Redis 调用示例：
redisTemplate.execute(script, Collections.singletonList("sms:limit:" + phone), String.valueOf(System.currentTimeMillis()), "60000") - 别把手机号直接当 key 名——要加前缀如
sms:limit:，避免和其他业务 key 冲突；也别用纯数字手机号当 key，防止被误扫
为什么短信发送前要校验两次：Redis 限流 + 本地缓存计数
Redis 网络延迟和瞬时抖动可能导致漏判，尤其在集群故障或连接池打满时。光靠 Redis 会放大误放行风险，而纯本地计数又无法跨实例同步。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 本地用
ConcurrentHashMap<string atomiclong></string>存最近 1 分钟每个手机号的计数（key 是手机号，value 是带时间戳的计数器） - 每次请求先查本地缓存：如果存在且时间未超 60 秒，且计数
- 本地缓存项 TTL 设为 70 秒（比窗口多 10 秒），避免刚过期就被重复创建
- 注意本地计数器不是替代 Redis，而是“快速通路 + 最终一致性保障”，Redis 结果永远以它为准
上线后监控不到限流效果？重点盯这三个 Redis 指标
很多团队只看业务日志里的“触发限流”打印，但真实瓶颈常藏在 Redis 层——比如 ZADD 延迟飙升、ZCOUNT 耗时突增、或 key 过大导致内存暴涨。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用
redis-cli --latency定期测实例延迟，超过 5ms 就要排查网络或慢查询 - 对限流 key 执行
MEMORY USAGE sms:limit:138****1234，单个 key 超过 1MB 必须优化（说明没及时清理或写入频率异常） - 开启 Redis 慢日志：
CONFIG SET slowlog-log-slower-than 10000，重点抓耗时 >10ms 的ZRANGEBYSCORE或ZREMRANGEBYSCORE - 别忘了监控
evicted_keys：如果大量 key 被驱逐，说明 maxmemory 不足，ZSET数据可能丢失，限流直接失效
滑动窗口真正的复杂点不在算法本身，而在 Redis 命令组合的原子性、毫秒级时间戳的精度传递、以及本地与远程状态的一致性维护——这三处任何一个松动，防刷就只是纸糊的墙。
