spring boot中用redis实现分布式幂等校验的核心是通过lua脚本原子性执行“判断存在→设锁→写结果”，结合业务唯一键生成可预测key，并借助aop声明式控制，辅以合理过期策略、降级方案与监控。
在 Spring Boot 中用 Redis 实现分布式幂等校验，核心是：**用 Redis 的原子操作（如 SETNX）生成唯一锁标识，结合业务唯一键（如请求 ID、订单号）做幂等控制，防止重复提交或重复执行**。关键不是“加锁再执行”，而是“先查状态再决定是否执行”，锁只是保障查询 + 写入过程的原子性。
1. 用 RedisTemplate + Lua 脚本保证原子性
单纯用 setIfAbsent 可能存在竞态（查无记录 → 加锁 → 执行 → 写结果），中间若服务宕机，锁释放但业务未完成，下次请求会误判为可执行。更可靠的方式是用 Lua 脚本把“判断是否存在 + 设置锁 + 设置业务结果”三步合并为原子操作。
示例 Lua 脚本（idempotent_lock.lua）：
if redis.call('exists', KEYS[1]) == 1 then
return 0 -- 已存在，拒绝执行
else
redis.call('setex', KEYS[1], ARGV[1], ARGV[2])
return 1 -- 成功加锁并写入
end
Java 调用方式：
• 注册脚本：
在配置类中加载 Lua 脚本为 RedisScript 对象，类型设为 Long.class。
• 执行脚本：
使用 redisTemplate.execute(script, Collections.singletonList(key), expireSeconds, value);
• 解释返回值：
返回 1 表示首次执行，可继续业务逻辑；返回 0 表示已存在，直接返回成功响应（或抛业务异常）。
2. 设计幂等 Key 的规范格式
Key 必须全局唯一且可预测，推荐组合：业务标识 + 唯一请求标识。例如：
• 订单创建："idempotent:order:create:" + userId + ":" + orderId
• 支付回调："idempotent:pay:notify:" + outTradeNo
• 注意：
避免直接用时间戳或随机 UUID 作 key 主体（不可重放）；
URL 参数、Header 中提取的 X-Request-ID 是常用可靠来源；
若前端不传，后端可基于请求参数（如 JSON body 的摘要）生成，但需确保相同参数一定生成相同 key。
3. 结合 AOP 实现声明式幂等控制
定义 @Idempotent 注解，标注在 Controller 方法上，自动提取 key、执行 Lua 校验、处理结果。
• 自定义注解：@Target(ElementType.METHOD)，支持指定 keySpEL 表达式（如 "#request.header['X-Request-ID']"）和过期时间。
• AOP 切面逻辑：
获取方法参数 → 解析 SpEL 得到 key → 执行 Lua 脚本 → 返回 0 则 throw IdempotentException（被全局异常处理器捕获，返回 200 + {"code":200,"msg":"重复请求"}）；
返回 1 则 proceed() 继续执行原方法。
• 补充建议：
方法执行成功后，可在 finally 块中异步记录日志或更新状态（如写 DB 的 idempotent_log 表），便于审计；
不要在切面里执行耗时业务（如调第三方接口），只做校验。
4. 容错与运维要点
生产环境不能只依赖 Redis 单点：
• 锁过期时间要合理：
太短（如 1s）可能导致业务未完成锁就失效，引发重复；太长（如 1 小时）影响故障恢复。建议设为业务平均耗时 × 3，上限 5~10 分钟。
• Redis 故障降级策略：
可配置开关，当 Redis 不可用时，改用本地缓存（Caffeine）+ 请求计数器（限流式兜底），或直接放行（配合人工对账）。
• 避免误删其他 key：
不要用 DEL 全删前缀 key，Lua 脚本内也不应 scan；如需清理，用带条件的 SCAN + 匹配删除，或靠 TTL 自动过期。
• 监控指标：
统计“幂等命中率”（返回 0 的次数 / 总请求数）、Redis 调用延迟、脚本执行失败率，接入 Prometheus。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
