在分布式系统中，原子性操作是保证数据一致性的关键。Redis的事务机制通过MULTI、EXEC等命令，实现了多个命令的批量执行与隔离性，为复杂业务场景提供了基础保障。本章将深入解析Redis事务的工作原理、使用方式及与其他原子性方案的对比，帮助你在实际开发中正确应用事务。

一、事务的核心特性：序列化与原子性

Redis事务的设计目标是保证一组命令的有序执行和原子性，具体表现为：

序列化执行：事务中的所有命令会按顺序执行，期间不会被其他客户端的命令打断（隔离性）。
原子性保证：事务要么全部命令都执行，要么都不执行。

若客户端在EXEC前断开连接，事务队列中的命令会被清空，不执行任何操作。
若EXEC被成功调用，所有命令会被执行（即使部分命令失败，其他命令仍会继续执行）。

二、事务的基本用法：从命令入队到执行

Redis事务通过四个核心命令实现：MULTI（标记开始）、EXEC（执行事务）、DISCARD（取消事务）、WATCH（乐观锁）。

1. 基础流程：MULTI+ 命令入队 + EXEC

# 标记事务开始
MULTI
# 命令入队（返回"QUEUED"表示成功入队）
INCR foo
INCR bar
# 执行事务（返回所有命令的结果数组）
EXEC
# 结果：
# 1) (integer) 1 （foo的自增结果）
# 2) (integer) 1 （bar的自增结果）

2. 取消事务：DISCARD

若在EXEC前需要放弃事务，可使用DISCARD清空命令队列并退出事务状态：

SET foo 100
MULTI
INCR foo
DISCARD  # 取消事务
GET foo  # 返回"100"（事务中的命令未执行）

三、事务中的错误处理：两种错误类型的区别

Redis事务对错误的处理方式与关系型数据库不同，需特别注意入队时错误和执行时错误的差异。

1. 入队时错误（EXEC前）

指命令在入队阶段因语法错误（如参数个数不对）或内存不足等原因无法入队。

表现：Redis会立即返回错误，标记事务为“无效”。
结果：EXEC执行时会直接返回错误，事务中的所有命令均不执行（Redis 2.6.5+行为）。

示例：

MULTI
INCR a b c  # 语法错误（INCR仅需1个参数）
-ERR wrong number of arguments for 'incr' command
EXEC  # 返回错误，事务不执行

2. 执行时错误（EXEC后）

指命令入队成功，但执行时因数据类型不匹配等原因失败（如对字符串执行LPOP）。

表现：错误命令返回具体错误信息，其他命令正常执行。
结果：Redis不会回滚事务，需由客户端自行处理失败命令。

示例：

SET a "string"  # a是字符串类型
MULTI
LPOP a  # 执行时会失败（对字符串执行列表操作）
INCR b  # 正常执行
EXEC
# 结果：
# 1) -ERR Operation against a key holding the wrong kind of value
# 2) (integer) 1 （b的自增结果）

四、为什么Redis不支持事务回滚？

与关系型数据库不同，Redis事务不支持回滚（Rollback），即使命令执行失败也不会撤销已执行的命令。原因如下：

错误类型可控：Redis命令失败通常是编程错误（如类型不匹配），这类错误应在开发阶段被发现，而非生产环境。
简化设计：省去回滚机制可减少Redis内部复杂度，提升性能。
回滚的局限性：回滚无法解决逻辑错误（如本应加1却加了2），这类问题需通过业务逻辑避免。

五、乐观锁：WATCH命令的CAS机制

WATCH命令为事务提供了检查并设置（CAS） 能力，可实现乐观锁，解决并发场景下的数据竞争问题。

1. 工作原理

WATCH key [key ...]：监视一个或多个键，若这些键在事务执行前被其他客户端修改，事务会被中止（EXEC返回nil）。
流程：监视键 → 读取值 → 事务入队 → EXEC（若监视的键未被修改，则执行；否则取消）。

2. 示例：解决并发自增的竞态条件

# 客户端A：监视mykey并准备自增
WATCH mykey
val = GET mykey  # 假设val=10
MULTI
SET mykey [val+1]  # 计划设置为11
EXEC  # 若mykey未被修改，返回OK；否则返回nil

# 若客户端B在A的WATCH和EXEC之间修改了mykey：
# 客户端B：SET mykey 20
# 则客户端A的EXEC返回nil，事务失败，需重试

3. WATCH的注意事项

EXEC或DISCARD执行后，所有监视会被自动取消。
客户端断开连接，监视也会失效。
可通过UNWATCH手动取消所有监视（适用于无需执行事务的场景）。

六、事务与脚本（Script）的对比

Redis的Lua脚本同样支持原子性操作，与事务相比各有优劣：

特性	事务（MULTI/EXEC）	Lua脚本（EVAL）
原子性	支持（所有命令作为整体执行）	支持（脚本内命令原子执行）
网络往返	需要多次交互（MULTI→命令→EXEC）	一次交互（脚本包含所有逻辑）
条件判断	依赖WATCH实现乐观锁	脚本内可直接写条件逻辑（更灵活）
错误处理	执行时错误不影响其他命令	可通过pcall捕获错误，灵活处理
适用场景	简单批量操作，需并发控制	复杂逻辑（含判断、循环），减少网络开销

最佳实践：简单批量操作可用事务，复杂逻辑（如“读-计算-写”）优先用Lua脚本。

七、事务的持久化保证

Redis事务在持久化层面有以下特性：

AOF持久化：事务中的所有命令会通过单个write系统调用写入AOF文件，保证写入的原子性（避免部分命令持久化）。
崩溃恢复：若Redis崩溃时事务未完成写入，重启时AOF文件会被标记为损坏，需用redis-check-aof工具修复（删除不完整的事务）。

八、总结：事务的适用场景与局限性

适用场景

批量执行多个命令，确保顺序性和原子性（如同时更新多个关联键）。
需简单并发控制（通过WATCH实现乐观锁）。

局限性

不支持回滚，执行时错误需客户端手动处理。
无法在事务中使用条件语句（需结合WATCH或Lua脚本）。
长时间运行的事务会阻塞其他命令，影响性能。

合理使用Redis事务，需结合业务场景选择合适的原子性方案——简单场景用事务，复杂场景用Lua脚本，必要时引入分布式锁（如Redlock）解决跨实例一致性问题。

四时宝库

程序员的知识宝库

Redis学习笔记:事务机制详解(第八章)