Redis事务详解

在高并发后端架构中，Redis凭借高性能的内存存储特性，成为缓存、分布式锁、实时计数、秒杀库存等场景的核心组件。而Redis事务作为保证一组操作原子性执行的关键机制，其设计逻辑与MySQL等传统关系型数据库事务差异显著，新手极易因理解偏差踩坑。本文将从Redis事务的定义、核心命令、执行流程、异常处理、并发控制到实战避坑，全程图文结合，让你彻底掌握Redis事务的使用与原理。

一、本文学习路线（流程图概览）

先明确整体学习结构，按节奏吃透Redis事务所有核心点：
开始
Redis事务核心定义：是什么？
核心命令：MULTI/EXEC/DISCARD/WATCH/UNWATCH
标准执行流程：3阶段执行原理
两类异常场景：入队错误&执行错误
WATCH乐观锁：并发控制实现
Redis vs MySQL事务：核心差异
实战场景+5大避坑指南
总结+进阶学习方向
结束

二、Redis事务核心定义：到底是什么？

Redis事务的本质是一组Redis命令的有序集合 ，其核心设计目标是保证这组命令的批量执行、串行执行 ，即在事务执行期间，不会被其他客户端的命令插队，以此实现弱原子性（区别于MySQL的强原子性）。

可以通俗理解为：Redis事务就是把多个命令"打包"，放入一个执行队列，最终要么按顺序执行队列中所有命令，要么在特定异常下放弃所有命令执行，不会出现"部分执行、部分未执行"的中间状态（执行时错误除外，后文详细讲解）。

新手必看：3个关键澄清

不支持回滚：这是Redis事务与MySQL事务最核心的区别，执行过程中出现错误不会回滚已执行的正确命令；
弱原子性：仅保证"要么全执行，要么全不执行"（入队错误场景），执行时错误会跳过错误命令，继续执行后续命令；
无隔离级别：Redis是单线程模型，事务内命令天然串行执行，不会出现脏读、不可重复读、幻读等问题，无需设计隔离级别。

三、Redis事务核心命令：5个命令吃透事务操作

Redis事务的所有操作均围绕5个核心命令展开，命令用法简单，重点记准作用和执行时机，即可快速上手，下表为详细说明：

命令	核心作用	关键说明
MULTI	开启事务	执行后客户端进入事务状态，后续命令不再立即执行，而是进入事务队列，返回QUEUED
EXEC	执行事务	触发队列中所有命令批量顺序执行，返回事务结果数组，执行后自动退出事务状态
DISCARD	放弃事务	清空事务命令队列，立即退出事务状态，所有入队命令均不执行
WATCH key1 key2...	监控键，实现乐观锁	监控指定key，EXEC执行前若key被其他客户端修改，事务直接终止，返回nil
UNWATCH	取消监控	取消所有WATCH监控的key，EXEC/DISCARD执行后会自动执行，无需手动调用

基础用法实战（可直接复制到Redis客户端执行）

场景1：正常执行事务

redis 复制代码

127.0.0.1:6379> MULTI  # 开启事务，进入TX状态
OK
127.0.0.1:6379(TX)> SET user:100 name "zhangsan"  # 命令入队，返回QUEUED
QUEUED
127.0.0.1:6379(TX)> HSET user:100 age 25 gender male  # 继续入队
QUEUED
127.0.0.1:6379(TX)> EXEC  # 执行事务，返回事务结果数组
1) OK
2) (integer) 2

场景2：放弃事务（DISCARD）

redis 复制代码

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> SET k1 v1
QUEUED
127.0.0.1:6379(TX)> DISCARD  # 取消事务，清空队列
OK
127.0.0.1:6379> GET k1  # 验证：k1未被创建
(nil)

场景3：取消监控（UNWATCH）

redis 复制代码

127.0.0.1:6379> WATCH k1 k2  # 监控k1、k2
OK
127.0.0.1:6379> UNWATCH  # 手动取消监控
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> SET k1 v1
QUEUED
127.0.0.1:6379(TX)> EXEC  # 无监控，正常执行
1) OK

四、Redis事务标准执行流程：3阶段+底层原理（附流程图）

Redis事务的执行全程分为开启事务、命令入队、执行/放弃事务 3个核心阶段，底层基于客户端状态标识 和命令队列实现，无复杂的事务日志，执行逻辑轻量高效。

4.1 标准执行流程图（可直接复制到CSDN）

执行EXEC
执行DISCARD
客户端发起请求
执行MULTI命令，开启事务
Redis标记客户端为CLIENT_MULTI状态
后续非事务命令依次入队，返回QUEUED
用户选择执行操作
Redis顺序执行队列中所有命令
Redis清空命令队列，放弃事务
返回事务执行结果数组（成功/失败）
返回OK，无执行结果
退出事务状态，重置CLIENT_MULTI标识

4.2 底层执行原理（极简C源码思路）

Redis底层通过客户端flags状态位 判断是否进入事务状态，核心处理逻辑简化后如下（便于理解，非完整源码），关键是命令入队 和直接执行的分支判断：

c 复制代码

// MULTI命令：开启事务
void multiCommand(client *c) {
    // 禁止嵌套事务，若已在事务状态则报错
    if (c->flags & CLIENT_MULTI) {
        addReplyError(c,"MULTI calls can not be nested");
        return;
    }
    // 标记客户端为事务状态
    c->flags |= CLIENT_MULTI;
    addReply(c,shared.ok);
}

// 核心命令处理逻辑：判断命令是入队还是直接执行
int processCommand(client *c) {
    // 若处于事务状态，且非EXEC/DISCARD/MULTI/WATCH命令，则入队
    if (c->flags & CLIENT_MULTI &&
        c->cmd->proc != execCommand && c->cmd->proc != discardCommand &&
        c->cmd->proc != multiCommand && c->cmd->proc != watchCommand)
    {
        queueMultiCommand(c);  // 命令入队，加入事务队列
        addReply(c,shared.queued);  // 返回QUEUED
    } else {
        call(c,CMD_CALL_FULL);  // 非事务命令，直接执行
    }
    return C_OK;
}

核心关键点：

事务状态由CLIENT_MULTI标识位控制，未开启时所有命令直接执行；
事务队列是有序队列，保证命令执行顺序与入队顺序一致；
EXEC执行后，事务队列会被清空，客户端状态重置为非事务状态。

五、Redis事务异常处理：2类错误+不同处理逻辑（重点避坑）

Redis事务的错误分为入队时错误 和执行时错误 两类，不同错误的处理逻辑完全不同，这也是Redis"弱原子性"和"不支持回滚"的核心体现，必须严格区分，否则会引发数据一致性问题。

5.1 类型1：入队时错误（语法/参数/类型错误）

错误特征

命令在入队阶段就被Redis检测到错误，如：命令拼写错误、参数个数不足、对字符串键执行列表操作（提前检测到键类型不匹配）。

处理逻辑

Redis会将该客户端标记为脏事务（CLIENT_DIRTY_EXEC） ，后续执行EXEC时，会直接放弃整个事务 ，所有命令均不执行，并返回EXECABORT错误。

异常流程图

MULTI开启事务，标记CLIENT_MULTI
命令1入队，正常返回QUEUED
命令2入队，检测到语法/参数错误
Redis标记客户端为CLIENT_DIRTY_EXEC（脏事务）
继续入队其他命令（可选）
执行EXEC命令
返回EXECABORT错误，放弃整个事务
所有命令均不执行，重置客户端状态

实战演示

redis 复制代码

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> SET k1 v1  # 正常入队
QUEUED
127.0.0.1:6379(TX)> SET k2  # 入队错误：缺少value参数
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379(TX)> SET k3 v3  # 事务已脏，仍可入队
QUEUED
127.0.0.1:6379(TX)> EXEC  # 执行事务，被拒绝
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> KEYS k*  # 验证：所有键均未创建
(empty array)

5.2 类型2：执行时错误（运行时/逻辑错误）

错误特征

命令在入队阶段无任何错误 （语法、参数、键类型均检测通过），但在EXEC执行阶段因数据状态或业务逻辑导致错误，如：对字符串键执行LPOP（入队时键不存在，无法检测类型）、数值运算时键为非数字值。

处理逻辑

Redis不会终止整个事务，也不会回滚已执行的正确命令 ，会跳过错误命令，继续执行队列中后续的所有正确命令，执行结果中会标注错误信息。

异常流程图

MULTI开启事务
命令1/2/3依次入队，均返回QUEUED
执行EXEC命令，开始顺序执行
命令1执行成功，返回结果
命令2执行，触发运行时错误
跳过命令2，标注错误信息
命令3继续执行，执行成功
返回事务结果数组（含成功/失败信息）
退出事务状态，不回滚任何命令

实战演示

redis 复制代码

127.0.0.1:6379> SET a "abc"  # 初始化a为字符串键
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> SET b 123  # 正常入队
QUEUED
127.0.0.1:6379(TX)> LPOP a  # 入队正常，执行时会报错（a是字符串）
QUEUED
127.0.0.1:6379(TX)> SET c 456  # 正常入队
QUEUED
127.0.0.1:6379(TX)> EXEC  # 执行事务，跳过错误命令
1) OK
2) (error) ERR Operation against a key holding the wrong kind of value
3) OK
127.0.0.1:6379> GET b  # 验证：b和c正常创建，无回滚
"123"
127.0.0.1:6379> GET c
"456"

5.3 关键疑问：Redis为什么不支持回滚？

Redis官方明确表示，不支持回滚并非设计缺陷 ，而是基于性能优化 和设计定位的双重考量，核心原因有3点：

错误类型为编程错误：Redis事务的执行错误大多是开发阶段的编程错误（如类型不匹配、参数错误），这类错误应在测试阶段发现并修复，而非运行时通过回滚处理；
简化实现，提升性能：省略回滚机制，让Redis事务的实现更轻量，无需维护undo log等事务日志，避免额外的性能损耗，符合Redis"高性能"的核心设计目标；
轻量级事务定位 ：Redis事务的设计目标是解决简单的批量执行和串行化问题，而非处理关系型数据库的复杂事务场景（如死锁、资源竞争），无需复杂的回滚逻辑。

六、WATCH乐观锁：Redis事务的并发控制方案（面试必考）

Redis事务本身不处理并发问题 ，若多个客户端同时修改同一组key，会导致数据不一致。此时需要配合WATCH命令 实现乐观锁（CAS：Compare And Swap），通过监控指定key的变化，保证并发场景下的事务原子性。

6.1 WATCH核心执行流程（流程图）

否（版本未变）
是（版本已变）
客户端1执行WATCH key，监控目标键
Redis记录key的当前版本（数据指纹）
客户端1执行MULTI，开启事务
相关命令入队，返回QUEUED
EXEC执行前，key是否被其他客户端修改？
正常执行事务，返回执行结果
事务直接终止，返回nil，不执行任何命令
自动取消WATCH监控，重置客户端状态

6.2 实战场景：高并发转账（WATCH+事务实现）

以用户A向用户B转账200元为例，需要保证"扣减A的余额"和"增加B的余额"的原子性，且防止并发修改导致的余额错误，核心是通过WATCH监控用户A的余额键。

步骤1：初始化用户余额

redis 复制代码

127.0.0.1:6379> SET userA 1000  # 用户A初始余额1000
OK
127.0.0.1:6379> SET userB 500   # 用户B初始余额500
OK

步骤2：客户端1开启监控+事务（准备转账）

redis 复制代码

127.0.0.1:6379> WATCH userA  # 监控userA，防止并发修改
OK
127.0.0.1:6379> MULTI  # 开启事务
OK
127.0.0.1:6379(TX)> DECRBY userA 200  # 扣减A200元，入队
QUEUED
127.0.0.1:6379(TX)> INCRBY userB 200  # 增加B200元，入队
QUEUED

步骤3：客户端2在EXEC前修改userA（模拟并发）

redis 复制代码

127.0.0.1:6379> DECRBY userA 100  # 客户端2扣减A100元，修改监控键
(integer) 900

步骤4：客户端1执行EXEC，事务终止

redis 复制代码

127.0.0.1:6379(TX)> EXEC  # userA被修改，事务返回nil
(nil)
# 验证：余额未发生错误变化，保证数据一致性
127.0.0.1:6379> GET userA
"900"
127.0.0.1:6379> GET userB
"500"

6.3 WATCH使用注意事项（3个关键点）

监控不存在的key ：WATCH可以监控不存在的key，若其他客户端创建该key，也会触发事务终止；
自动取消监控 ：EXEC/DISCARD执行后，WATCH的监控会自动取消 ，若需重新执行事务，需重新调用WATCH；
适用场景限制 ：WATCH仅适用于低并发场景 ，高并发下会导致事务频繁失败（返回nil），此时需结合Redis分布式锁（SET NX EX） 或Redlock实现。

七、Redis事务 vs MySQL事务：核心差异对比（面试高频）

很多面试官会考察Redis事务与MySQL事务的区别，核心差异体现在原子性、隔离性、持久性等6个维度，下表为详细对比，清晰好记：

对比维度	Redis事务	MySQL事务（InnoDB引擎）
原子性	弱原子性，不支持回滚，执行时错误跳过错误命令	强原子性，支持回滚（undo log），要么全成要么全败
隔离性	天然串行执行，无隔离级别，无脏读/不可重复读/幻读	支持4种隔离级别，需通过锁和MVCC解决并发问题
持久性	依赖RDB/AOF持久化配置，默认不保证事务结果持久化	基于redo log，默认保证持久性，事务提交即落盘
一致性	仅保证执行层面的简单一致性，不处理复杂业务异常	严格保证数据一致性，通过事务日志和锁机制实现
实现方式	命令入队+批量执行，轻量级，无任何事务日志	redo log/undo log+行锁/表锁，重量级，依赖日志恢复
适用场景	缓存更新、简单计数、低并发原子性、批量命令执行	订单交易、转账支付、高并发强一致性、复杂业务逻辑

八、Redis事务实战场景+5大避坑指南（重点！）

8.1 Redis事务适用场景

Redis事务是轻量级原子性机制，并非万能，需结合其特性选择合适场景，推荐使用场景如下：

批量更新缓存：修改用户信息、商品信息时，同步更新多个缓存键，保证一组键的修改同时生效；
简单原子性操作：低并发下的库存扣减、余额修改、积分增减，配合WATCH实现并发控制；
多命令串行化：保证一组命令的执行顺序，防止被其他客户端命令插队，如"查询+修改"的组合操作；
轻量级批量操作：一次性执行多个非耗时命令，减少网络交互次数，提升执行效率。

8.2 新手必避5大深坑（面试高频+实战踩坑）

坑1：误以为Redis事务支持回滚

问题：执行时错误后，期望Redis回滚已执行的命令，导致数据一致性问题；
解决方案 ：开发时严格校验命令语法/参数/键类型，运行时逐行判断EXEC返回结果 ，发现错误时手动补偿数据（如删除已执行命令产生的键值）。

坑2：高并发下仅用WATCH+事务

问题：高并发场景下，WATCH监控的key极易被修改，导致事务频繁返回nil，执行失败；
解决方案 ：低并发用WATCH+事务+重试机制，高并发场景使用Redis分布式锁（SET NX EX PX） 或Redisson，保证同一时间只有一个客户端修改数据。

坑3：嵌套使用MULTI命令

问题：在已开启的事务中再次执行MULTI，直接触发报错，导致事务开启失败；
解决方案 ：业务代码中增加事务状态判断，避免重复调用MULTI；或执行EXEC/DISCARD后，再重新开启事务。

坑4：忽略WATCH的自动失效机制

问题：EXEC执行后未重新WATCH，直接再次开启事务，导致无并发控制；Redis6.0.9前，过期key不会触发WATCH事务终止；
解决方案 ：每次开启事务前重新执行WATCH；升级Redis至6.0.9+版本，或手动校验监控key的有效性（如判断是否过期）。

坑5：事务中执行耗时命令

问题：Redis是单线程模型，事务内执行KEYS *、HGETALL、SMEMBERS等耗时命令，会阻塞整个Redis实例，影响其他客户端；
解决方案 ：禁止在事务中执行耗时命令，批量查询建议使用分批操作，大键操作单独执行，避免阻塞。

九、总结：Redis事务核心知识点回顾

Redis事务的核心是MULTI-EXEC 的轻量级批量执行机制，配合WATCH实现简单的并发控制，其核心特点可总结为3支持+2不支持：

3个支持

支持批量执行：多个命令打包入队，一次性执行；
支持串行执行：事务执行期间不被其他客户端命令插队；
支持乐观锁：通过WATCH实现CAS机制，解决低并发下的并发问题。

2个不支持

不支持回滚：执行时错误不会回滚已执行的正确命令；
不支持复杂隔离级别：天然串行执行，无需设计隔离级别。