Java短信发送防刷机制：滑动窗口与Redis时间戳实现

本文深入剖析了Java应用中短信发送防刷的核心难点，指出单纯依赖Redis的INCR+EXPIRE无法抵御“窗口边缘刷量”，必须采用ZSET结合毫秒级时间戳实现真正滑动窗口限流；强调Lua脚本原子执行ZREMRANGEBYSCORE、ZCOUNT与ZADD的必要性，并创新性提出“Redis兜底+本地ConcurrentHashMap缓存计数”的双校验机制以平衡性能与一致性；同时给出上线后精准监控Redis延迟、内存占用和慢日志的关键实践——揭示防刷不是算法炫技，而是原子性、精度与容错三重能力的严丝合缝。

滑动窗口限流为什么必须用 Redis 的 ZSET 而不是 INCR + 过期时间

因为单靠 INCR 和 EXPIRE 只能做固定窗口，无法应对“窗口边缘刷量”——比如用户在第 59 秒发 5 条，第 60 秒又发 5 条，两个窗口各算 5 条，实际 2 秒内就触发了 10 次请求。ZSET 可以按时间戳精确存每条请求，再用 ZRANGEBYSCORE 查过去 60 秒内所有记录，真正实现滑动效果。

实操建议：

• 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 脚本原子执行，否则限流就形同虚设。

实操建议：

• 脚本里先 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 会放大误放行风险，而纯本地计数又无法跨实例同步。

实操建议：

• 本地用 ConcurrentHashMap 存最近 1 分钟每个手机号的计数（key 是手机号，value 是带时间戳的计数器）
• 每次请求先查本地缓存：如果存在且时间未超 60 秒，且计数
• 本地缓存项 TTL 设为 70 秒（比窗口多 10 秒），避免刚过期就被重复创建
• 注意本地计数器不是替代 Redis，而是“快速通路 + 最终一致性保障”，Redis 结果永远以它为准

上线后监控不到限流效果？重点盯这三个 Redis 指标

很多团队只看业务日志里的“触发限流”打印，但真实瓶颈常藏在 Redis 层——比如 ZADD 延迟飙升、ZCOUNT 耗时突增、或 key 过大导致内存暴涨。

实操建议：

• 用 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 命令组合的原子性、毫秒级时间戳的精度传递、以及本地与远程状态的一致性维护——这三处任何一个松动，防刷就只是纸糊的墙。

今天关于《Java短信发送防刷机制：滑动窗口与Redis时间戳实现》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！