spring boot 中用 redis 实现高并发限流保护，核心是通过原子命令（如 incr + expire 或 lua 脚本）完成“计数+过期”一体化操作，确保时间窗口内请求不超阈值；结合分布式锁保障多步强一致业务安全；缓存则支撑维度化限流与穿透防护，形成「原子计数、自动过期、安全释放、降级兜底」的闭环机制。
在 Spring Boot 中用 Redis 实现高并发限流保护，核心是把缓存、分布式锁和原子计数三者协同起来：缓存承载高频访问数据，分布式锁保障临界操作安全，原子命令（如 INCR + EXPIRE）实现毫秒级限流判断。这不是简单堆砌功能，而是围绕「时间窗口 + 请求计数 + 自动过期 + 安全释放」构建一套闭环机制。
限流逻辑必须基于原子操作
不能先查再判再增（非原子），否则高并发下会漏放或超限。正确做法是用 Redis 的单线程特性，靠一条命令完成“尝试自增并设置过期”：
- 使用
INCR key增加计数器，返回当前值 - 首次调用时配合
EXPIRE key, windowSeconds设置整个窗口过期时间（注意：需用 Lua 脚本或 RedisTemplate 的opsForValue().increment()+expire()组合，并确保两个操作在同一个连接中执行，避免竞态） - 更稳妥的方式是封装 Lua 脚本，把 INCR 和 EXPIRE 合并在服务端原子执行，例如：
local current = redis.call("INCR", KEYS[1])
if current == 1 then
redis.call("EXPIRE", KEYS[1], ARGV[1])
end
return current
分布式锁用于关键资源的串行化控制
限流本身不总需要锁，但当业务逻辑涉及「检查库存→扣减→写日志」这类多步强一致操作时，就得加锁。Redis 分布式锁要满足三个基本条件：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
唯一性：锁 key 带业务标识和唯一 client ID（如
lock:order:create:1001+ UUID），防止误删 - 自动过期：SET key value EX seconds NX，既设值又设过期，避免死锁
- 安全释放：删除锁必须用 Lua 脚本比对 value 再 DEL，杜绝 A 创建、B 误删
缓存与限流的协同设计
缓存在这里不只是加速读，更是限流策略的支撑层：
- 用户维度限流：缓存 key 设计为
rate:uid:12345:2026081314（按小时窗口），value 存当前请求数；每次请求前先INCR，再判断是否 ≤ 阈值 - 接口维度限流：key 为
rate:api:/pay:60s，配合 Redis 的 TTL 自动清理旧窗口 - 缓存穿透防护：对空结果也缓存短时间（如 2 分钟），避免恶意刷不存在的 uid 导致打穿数据库
生产环境必须考虑的细节
光跑通逻辑不够，上线前得确认这几件事：
- Redis 连接池配置合理（Lettuce 推荐 max-active ≥ 50，min-idle ≥ 10），避免限流逻辑自身被连接阻塞
- 限流失败时返回明确状态码（如 429 Too Many Requests）和提示，前端可做友好降级
- 监控 key 的命中率与过期率，用 Redis 的
INFO stats或 Prometheus + Grafana 看instantaneous_ops_per_sec和expired_keys - 兜底方案：Redis 不可用时自动降级为本地限流（如 Guava RateLimiter），避免雪崩
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
