可行但必须用SET key value NX EX/PX原子命令，否则SETNX与EXPIRE非原子执行，服务宕机时锁永久残留导致假幂等。
直接结论：用 SETNX 做幂等标志位可行，但必须搭配过期时间（EX 或 PX）和原子性校验，否则在节点宕机、网络分区或业务异常中断时会永久卡死。
为什么不能只用 SETNX 单独判断
很多人写成 redis.setnx(key, "1") 后直接判断返回值，再手动调 expire —— 这是典型错误。因为 SETNX 和 EXPIRE 是两个独立命令，中间若服务崩溃或进程退出，key 就会永远存在，后续所有同请求都被拦截，变成“假幂等”。
- Redis 2.6.12+ 支持原子写法：
SET key value NX EX seconds，这才是安全起点 - 旧版本 Redis（SETNX + EXPIRE，否则不保证原子性
- 不要依赖客户端本地时间生成过期逻辑，全部交由 Redis 服务端控制
SET 命令的 NX 模式比 SETNX 更推荐
SETNX 是独立命令，而 SET key val NX EX 60 把存在性判断、赋值、过期三件事压进一次网络往返，既减少 RTT，又规避竞态窗口。实际生产中应优先用这个组合。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
NX表示“仅当 key 不存在时才设置”，语义清晰，和SETNX完全等价 -
EX（秒）或PX（毫秒）必须显式指定，建议按业务耗时 × 2～3 倍设，比如下单逻辑通常 2s 内完成，设EX 10较稳妥 - 避免用
XX（仅存在时设置），它对幂等场景无意义，反而容易掩盖 key 残留问题
标志位 key 的设计必须带业务上下文
只用 request_id 作 key 看似简单，但跨服务、跨版本、跨环境时极易冲突或误删。真正健壮的做法是把关键业务维度编码进 key 名。
- 推荐格式：
idempotent:{service}:{resource}:{method}:{sign}，例如idempotent:order:pay:POST:uid123_ord456_amt789 - sign 应基于请求参数做确定性哈希（如 SHA256），而非原始 JSON 字符串——避免空格、换行、字段顺序导致哈希不一致
- 绝对不要用时间戳、随机数、session id 等不可复现字段参与 sign 计算，否则相同请求每次生成不同 key，失去幂等意义
- key 长度别超 1024 字节，Redis 对 key 长度有限制，过长会导致 SET 失败且无明确报错
释放锁 ≠ 删除 key，要防止误删
有些方案在业务成功后主动 DEL key，这很危险：如果执行到一半机器重启，或者 DEL 请求丢失，key 仍会靠过期自动清理；但如果 DEL 被其他并发请求误发（比如 A 请求处理慢，B 请求超时重试并误删了 A 的 key），就会破坏幂等性。
- 正确做法：业务逻辑完成后，不再主动删 key，完全依赖
EX自动过期 - 若需提前释放（如业务明确取消），必须用 Lua 脚本先校验 value 是否匹配再删，例如：
EVAL "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end" 1 idempotent:xxx "token_a" - value 不要固定写死为
"1"或"true"，应写入唯一 token（如 UUID），用于后续校验，避免多个请求共用一个 key 时互相覆盖
最常被忽略的一点：幂等标志位的生命周期必须严格大于业务最大可能耗时，但又不能太长——太短会导致正常重试被拒绝，太长则占用内存、拖慢 key 清理。这个平衡点需要结合链路监控数据反复调整，而不是拍脑袋设个 60 秒就完事。
