redis分布式锁实现幂等性的核心是同一请求标识在同一时间只能被一个节点处理，关键在于业务可识别的唯一key设计、原子性加锁带超时（set...nx ex）、失败时静默返回而非重试。
用 Redis 分布式锁保证微服务接口幂等性，核心是「同一请求标识（idempotent key）在同一时间只能被一个节点处理」。它不依赖数据库主键或版本号，适合高并发、跨服务的场景，关键是锁的粒度、生命周期和释放可靠性要设计到位。
锁的 key 必须唯一且可业务识别
不能简单用固定字符串，得从请求中提取出能代表「一次业务意图」的字段组合。比如：
- 支付回调：用 商户号 + 支付流水号 拼接，如
pay:mid123:trade_no456 - 创建订单：用 用户ID + 商品SKU + 时间戳前8位，避免纯时间戳冲突
- 注解方式（如
@Idempotent(key = "#dto.orderNo")）：通过 SpEL 解析参数，动态生成 key
key 设计错误会导致锁失效（不同业务共用一把锁）或过度竞争（相同业务被拆成多个 key）。
加锁必须带超时，且避免死锁
Redis 锁必须设置过期时间（EX），否则节点宕机后锁永远不释放。推荐用原子命令一步完成加锁+设过期：
-
SET idempotent:order_789 "locked" EX 30 NX—— 30 秒自动过期，NX 确保只在 key 不存在时设置成功 - 不要分两步：
SET+EXPIRE，中间可能崩溃导致锁无过期时间 - 超时时间建议略大于业务最大执行耗时（如业务最长 8 秒，设 15–20 秒）
成功加锁才执行业务，失败直接返回
切面或拦截器中，加锁返回 true 才放行；若返回 false（表示已存在），说明该请求正在处理或已处理完，应：
- 立即返回「处理中」或「重复请求」提示（前端可据此禁用按钮）
- 不抛异常、不重试、不写日志告警（这是正常幂等行为，不是错误）
- 如果需要返回历史结果，可额外查缓存（如把上次响应体存 Redis，key 相同）
业务完成后主动清理或依赖自动过期
锁本身不需要手动删除——靠 EX 自动释放最安全。但要注意：
- 不要在 finally 里 DEL key：可能删掉别人刚续上的锁（分布式环境下无法判断锁归属）
- 若需延长锁（如业务执行慢），要用 Lua 脚本校验 value 再更新过期时间
- 更稳妥的做法是：业务成功后，把该 key 的值设为
success并延长 TTL（如 24 小时），后续请求看到 success 就直接返回结果
不复杂但容易忽略细节，关键就三点：key 可业务对齐、加锁原子且带过期、失败路径走静默返回而非重试。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
