Redis事务不支持回滚不是缺陷，而是为追求单线程极致性能和实现简洁性的主动设计取舍；错误应在开发阶段预检，而非依赖运行时回滚。
Redis 事务不支持回滚，不是缺陷，而是设计取舍——它用“不回滚”换来了单线程下的极致执行效率和实现简洁性。业务中若照搬 MySQL 的事务思维，很容易踩坑：比如某条 LPUSH 因 key 类型错误失败，前面的 SET 却已生效，导致数据半写、状态不一致。
提前校验 + 命令预检
Redis 不会在入队阶段报错（如对 string 执行 LPUSH），但多数错误其实在业务逻辑层就能预判。关键是在调用 MULTI 前做类型与存在性检查：
- 读取目标 key 的类型（
TYPE key），确认是否匹配后续操作（如要INCR就确保是 string；要HGETALL就确保是 hash） - 对依赖 key 存在性的操作（如
DECRBY order_count），先用EXISTS判断，不存在则跳过或补初始化 - 避免在事务中混用读写——
GET后再SET这类依赖中间结果的逻辑，应拆到客户端判断后分步执行
用 WATCH 实现乐观锁式“软回滚”
WATCH 不是回滚机制，但它能防止脏写，让失败发生在执行前，从而规避“部分成功”问题：
- 对关键业务字段（如库存、余额）使用
WATCH stock:1001，再MULTI→ 修改命令 →EXEC - 如果
EXEC返回nil，说明期间被其他客户端改过，此时可重试整个业务流程（含重新读取最新值、重新计算） - 注意：WATCH 只监控 key，不监控 value；且仅对被 watch 的 key 生效，未 watch 的 key 改动不影响事务
拆分事务粒度，让失败影响可控
不要把跨领域操作塞进一个事务。例如“下单+扣库存+生成日志”这种组合，应拆成：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 独立事务 A：扣库存（watch stock:key，失败则拒绝下单）
- 独立事务 B：写订单（用唯一订单号做幂等控制）
- 异步任务 C：补日志（失败可重试，不阻塞主链路）
每个事务只做一件事，失败时边界清晰，补偿或重试逻辑也更简单。
用 Lua 脚本替代 MULTI/EXEC
Lua 脚本在 Redis 中是原子执行的，天然规避了“部分失败”问题，适合强一致性场景：
- 把多步逻辑（如“读旧值→计算新值→写入→返回结果”）封装进一个脚本，用
EVAL提交 - 脚本内可做 if 判断、类型检查、错误 early-return（用
redis.error_reply） - 注意：Lua 执行时间不能过长（避免阻塞其他请求），复杂计算建议移至客户端
不复杂但容易忽略：Redis 事务不是用来兜底的，而是用来“打包顺序执行”的。真正需要 ACID 的环节，该交给 MySQL 或 PostgreSQL；Redis 的角色，是快、轻、确定——把不确定性挡在门外，而不是留在里面处理。
