Redis不支持真正ACID事务，MULTI/EXEC仅保证命令排队与顺序执行，无回滚能力；WATCH可实现乐观锁式跨key检查，需应用层重试；强一致性场景应优先用Lua脚本或关系型数据库。
Redis 本身不支持跨 Key 的真正事务（比如像 MySQL 那样带回滚、条件判断、隔离级别的 ACID 事务），MULTI 和 EXEC 只是把多个命令打包、顺序执行，并不能解决“某个 Key 修改失败后其他 Key 自动还原”的问题。但如果你的目标是「防止命令被插队 + 保证执行顺序 + 尽可能原子提交」，那 MULTI/EXEC 是唯一可用的原生机制。
为什么 MULTI/EXEC 不能真正实现跨 Key 事务
根本原因在于 Redis 事务不提供回滚能力 —— 它只做两件事：排队、按序执行。一旦 EXEC 开始运行，哪怕中间某条命令报错（比如对字符串执行 INCR），前面已成功的命令不会撤销，后面命令也照常执行（除非是入队阶段就语法错误，整个事务直接被拒绝）。
-
SET key1 "hello"→ 成功 -
INCR key1→ 报错(error) ERR value is not an integer or out of range -
SET key2 "world"→ 依然成功
最终结果是 key1 值不变、key2 已写入 —— 这不是事务，是“尽力而为的串行执行”。
WATCH 怎么配合 MULTI/EXEC 实现乐观锁式跨 Key 操作
当你需要“多个 Key 同时未被修改才执行更新”，就得靠 WATCH。它不是事务的一部分，而是前置检查机制：在 MULTI 之前监视一个或多个 Key，如果这些 Key 在 EXEC 前被其他客户端改过，EXEC 就返回 nil，整个事务失效。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
WATCH必须在MULTI之前调用，且只对当前连接有效 - 被
WATCH的 Key 被任意客户端执行SET、DEL、INCR等写操作即触发失效（读操作不影响） -
EXEC返回nil表示失败，此时应用层需重试或放弃 - 常见误用：
WATCH后又执行了未被监视的 Key 写操作，不影响事务，但可能破坏业务逻辑一致性
示例（伪代码逻辑）：
WATCH stock:1001 price:1001 MULTI DECR stock:1001 INCRBY price:1001 5 EXEC
若另一客户端在 EXEC 前改了 stock:1001，本次 EXEC 返回 nil，你得自己处理重试逻辑。
实际开发中该不该依赖 Redis 事务
多数场景下，不建议把业务强一致性押在 Redis 事务上。更稳妥的做法是：
- 用 Lua 脚本替代
MULTI/EXEC：单次请求、原子执行、可含逻辑判断，且天然避免竞态（如库存扣减+订单生成） - 关键数据落地到关系型数据库，Redis 仅作缓存或状态快照
- 若必须用
MULTI/EXEC，务必搭配WATCH+ 应用层重试，且预估好重试开销 - 避免在事务中混用读写 ——
GET类命令无法获取事务内尚未提交的变更，容易写出逻辑漏洞
最容易被忽略的一点：Redis 事务的“原子性”仅体现在执行顺序和无插队上，跟数据一致性毫无关系。别指望它能兜底业务逻辑错误。
