decr能保证库存扣减原子性，因其是redis单命令执行，服务端一次完成“读-改-写”，由单线程事件循环处理，避免并发竞争；而get+set模拟减法会导致超卖。
DECR 为什么能保证库存扣减的原子性
因为 DECR 是 Redis 服务端单命令执行，不依赖客户端逻辑，整个“读-改-写”过程在服务端一次完成，不存在并发读取旧值后覆盖的问题。它底层由 Redis 单线程事件循环直接处理，天然规避了多线程竞争条件。
常见错误现象：用 GET + SET 模拟减法（比如先读库存，再算新值，再写回），在高并发下必然超卖——两个请求同时读到 10，各自减 1 后都写回 9。
-
DECR只适用于整数库存，且初始值必须是数字字符串（如"100"），不能是"100.5"或"null" - 如果 key 不存在，
DECR会先初始化为 0 再减 1，结果为 -1 —— 这通常不是你想要的，得提前SET初始库存 - 返回值是执行后的当前值，可直接用于判断是否扣减成功（比如返回
库存为零时继续 DECR 会怎样
会照常执行，返回负数。Redis 不做业务语义校验，DECR 本身不拒绝负值，这意味着“超卖”不会被自动拦截，必须由你主动检查返回值。
使用场景：秒杀、抢购类系统中，不能只靠 DECR 完事，必须结合返回值做判断。
- 正确做法：用
DECR扣减后，立即判断返回值是否 INCR 回滚，并返回“库存不足” - 注意
INCR回滚不是万能的——如果此时有其他请求并发执行了DECR，回滚可能把别人刚扣的份额也加回来了 - 更稳妥的方式是用 Lua 脚本把“判断+扣减+失败回滚”打包成一个原子操作，避免两次网络往返间的竞态
DECR 在分布式环境下的真实限制
它只保证单个 Redis 实例内的原子性。如果你用了 Redis Cluster，key 的 slot 决定了它落在哪个分片上；只要库存 key 始终路由到同一个节点，DECR 就仍然可靠。但一旦涉及多个 key（比如扣库存 + 写订单），就无法靠 DECR 保证跨 key 原子性。
性能影响：DECR 是 O(1) 操作，吞吐极高，单节点轻松扛几万 QPS。但别忘了网络延迟和客户端连接池配置——如果每次扣减都新建连接，瓶颈根本不在 Redis。
- 确保库存 key 使用固定 hash tag（如
stock:{1001}），防止 Cluster 下被拆到不同节点 - 不要用
DECRBY随意传入变量值，尤其是用户可控的参数，否则可能被用来恶意刷负库存 - 监控
DECR的返回分布：长期出现大量负值，说明上游限流或预校验失效了
用 Lua 脚本封装安全扣减的必要性
当“检查库存 ≥ 1”和“执行扣减”必须严格绑定，且不允许任何中间状态被外部观察或干扰时，纯 DECR 不够用。Lua 脚本在 Redis 中以原子方式执行，是唯一能补上这道缝的方案。
示例脚本逻辑：if redis.call("GET", KEYS[1]) >= ARGV[1] then return redis.call("DECRBY", KEYS[1], ARGV[1]) else return -1 end —— 注意这里用的是 DECRBY 和数值参数，比单纯 DECR 更灵活。
- Lua 脚本里不能调用带随机性或外部依赖的命令（如
TIME、SRANDMEMBER），否则在 AOF 重放或主从同步时行为不一致 - 脚本长度建议控制在 1KB 内，过长会影响 Redis 主线程响应，尤其在慢日志较多时
- 首次运行脚本要用
EVAL，后续用EVALSHA提升性能；但要注意脚本变更后EVALSHA会失败，需降级处理
真正麻烦的从来不是 DECR 本身，而是你怎么定义“扣减成功”——是只要命令没报错？还是必须返回非负值？又或者要连带生成订单流水？这些边界一旦模糊，原子性就只是幻觉。
