Redis防刷计数器核心是“加得准、控得住、不误杀、扛得住洪峰”，依赖单线程原子性、合理key设计（带业务粒度前缀+时间切片）、精准TTL策略协同实现；采用分桶固定窗口+客户端补偿替代滑动窗口，兼顾性能与精度。
用 Redis String 配合 INCRBY 实现防刷计数器，关键不在“能不能加”，而在于“加得准、控得住、不误杀、扛得住洪峰”。它的高可靠性不来自复杂逻辑，而是靠 Redis 单线程原子性 + 合理的 key 设计 + 精准的过期策略三者协同。
防刷计数器的核心设计原则
防刷不是单纯限制“总次数”，而是约束“单位时间内的行为频次”，比如：每分钟最多发 5 条短信、每小时最多提交 10 次表单、每个 IP 每天最多登录 3 次。因此计数器必须自带时间维度，且不能依赖客户端时间或服务端本地时钟——必须由 Redis 自身承载时效语义。
-
时间切片化：把“窗口”变成可落地的 key 后缀，例如用
phone:138****1234:2026052013表示“手机号在 2026-05-20 13 点的计数”，或更通用的ip:192.168.1.100:rate_60s+ TTL 60 秒 -
key 必须带业务粒度前缀：区分用户 ID、设备指纹、IP、手机号、接口路径等维度，避免一个热点 key 成为瓶颈（如全站共用一个
global_counter） - value 只存整数，且初始化即合规：INCRBY 要求 value 是合法数字字符串；不要先 SET JSON 再 INCRBY，否则直接报错 ERR value is not an integer
抗洪峰的关键操作：原子递增 + 条件过期
高并发下最常见错误是“先 INCRBY，再 EXPIRE”，两步非原子，若中间崩溃，key 就永久残留。正确做法是让过期只在首次创建时设置：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 调用
INCRBY key step，获取返回值new_val - 若
new_val == step（说明 key 原本不存在，本次是首次写入），立即执行EXPIRE key ttl_seconds - 注意：不能用
SET key 0 EX 60初始化，因为 SET 和 EXPIRE 不是一条命令，存在竞态空窗 - 在 Java 中使用 RedisTemplate，推荐封装成工具方法：
redisTemplate.opsForValue().increment(key, step)后判断返回值是否等于 step，再调用expire(key, ttl, TimeUnit.SECONDS)
防误杀与精准限流：滑动窗口的轻量替代方案
严格滑动窗口（如 Redis + Lua 实现 ZSET 滚动统计）性能开销大，对大多数防刷场景属于过度设计。推荐“分桶固定窗口 + 客户端补偿”组合：
- 按分钟建桶：
user:1001:login:202605201423（精确到分钟），TTL 设为 65 秒，确保跨分钟请求能被新旧桶覆盖 - 当请求到达，同时对当前分钟桶和上一分钟桶做 INCRBY，并检查两者之和是否超限
- 若总和 ≤ 阈值，放行；否则拒绝，并返回剩余等待时间（如“请 57 秒后重试”）
- 该方式无锁、无 Lua、无 ZSET，纯 String + 常规命令，QPS 轻松破 10 万+
生产级加固建议
真正上线前，还需补上几道防线：
-
Key 命名规范化：统一格式如
{type}:{identity}:{scope}:{window}，例如sms:139****5678:verify:60s，便于监控、清理与分片 - 拒绝非法输入导致的 key 泛滥：对 identity 字段（如手机号、IP）做基础校验和标准化（去空格、补全 IP 段），防止恶意构造 key 打爆内存
- 配置分级阈值：普通用户 5 次/分钟，VIP 用户 20 次/分钟，通过读取配置中心动态加载，避免硬编码
- 记录触发日志但不阻塞主流程：防刷拦截可异步写入 Kafka 或本地日志，避免 Redis 延迟影响主业务响应
