Redis 支持事务吗？如何实现？

Redis 事务机制详解

【核心定义】

Redis 事务是一种将多个命令打包、按顺序一次性执行的机制，它通过 MULTI、EXEC、DISCARD、WATCH 等命令实现，但不支持回滚，与传统数据库的 ACID 事务有本质区别。

【关键要点】

事务三阶段
- 开启阶段：MULTI 命令标记事务开始，后续命令进入队列缓存
- 命令入队：客户端发送的命令不会立即执行，而是加入 FIFO 队列
- 执行阶段：EXEC 触发队列中所有命令的原子性执行
原子性特点
- Redis 事务的原子性指：所有命令一起成功或一起失败
- 但执行错误不会回滚已执行的命令（与传统数据库关键区别）
错误处理机制
- 入队错误（语法错误）：整个事务拒绝执行，EXEC 返回错误
- 执行错误（运行时错误）：仅该命令失败，其他命令继续执行
乐观锁实现
- WATCH 命令监控键值变化，若被修改则事务执行失败
- 基于 CAS（Compare-and-Swap）思想，解决并发竞争问题

【深度推导/细节】

事务执行流程拆解

Step 1: 客户端发送 MULTI
        → 服务器标志事务开始，返回 OK

Step 2: 客户端发送命令（如 SET、GET）
        → 服务器检查命令语法
        → 语法正确：加入队列，返回 QUEUED
        → 语法错误：记录错误标志

Step 3: 客户端发送 EXEC
        → 服务器检查：
           a) 有入队错误 → 返回错误，放弃执行
           b) 有 WATCH 键被修改 → 返回 nil，事务失败
           c) 正常情况 → 按顺序执行所有命令，返回结果数组

为什么不支持回滚？

设计哲学决定：

性能优先：回滚需要保存执行前状态，影响 Redis 的高性能特性
错误预防：Redis 认为错误应在开发阶段发现，而非运行时
简单性：保持核心简单，复杂事务需求应使用数据库

WATCH 机制深度解析

# 典型使用模式
WATCH balance          # 监控余额键
balance = GET balance  # 读取当前值
MULTI
DECRBY balance 100     # 减少余额
EXEC                   # 如果期间 balance 被其他客户端修改，则返回 nil

实现原理：

每个 Redis 数据库维护 watched_keys 字典
键被修改时，所有监视该键的客户端事务标志设为失败
EXEC 执行前检查失败标志，决定是否执行

【关联/对比】

Redis 事务 vs 数据库 ACID 事务

特性	Redis 事务	传统数据库事务
原子性	命令级原子性	语句级原子性
一致性	部分保证	完全保证
隔离性	单线程天然隔离	多隔离级别
持久性	依赖 RDB/AOF	WAL 日志保证
回滚	不支持	支持