Redis 事务（一文讲透）

Redis 事务：理解与实战

在高并发的互联网系统中，数据一致性是一个绕不开的话题。当我们需要执行一系列操作，并希望它们要么全部成功，要么全部失败时，Redis 事务就成为了一个非常实用的工具。它不是传统数据库那种复杂的 ACID 事务，但它的轻量级设计让开发者在缓存场景下能高效地保证操作的原子性。

Redis 事务的核心目标是：将多个命令打包成一个整体，按顺序执行，中途不被其他客户端打断。虽然它不支持回滚（rollback），但通过命令队列和执行机制，依然能为开发带来极大的便利。

什么是 Redis 事务？

想象一下你在银行办理业务，需要先从 A 账户转 100 元到 B 账户，然后再更新账户余额记录。如果这两个操作中间被别人插队，可能会导致金额不一致。Redis 事务就像一个“业务窗口”，在你进入之后，其他人都得排队等你完成所有操作再处理。

在 Redis 中，事务通过 MULTI、EXEC 和 DISCARD 三个命令来控制：

  • MULTI：开启事务，后续所有命令被放入队列。
  • EXEC：执行队列中的所有命令，返回结果。
  • DISCARD：取消事务，清空命令队列。

这个流程类似于你点餐后，服务员先记下所有菜名，最后一次性端上桌。如果中途发现菜单错了，也可以选择取消。

Redis 事务的工作机制

Redis 事务并不是真正意义上的“原子性”事务（即不支持回滚），它更像是一种“命令批处理”机制。下面我们通过一个例子来理解它的行为。

MULTI

SET user:balance:1001 1000
INCR user:balance:1001
DECR user:balance:1001

EXEC

执行结果：

1) OK
2) (integer) 1001
3) (integer) 1000

详细解析：

  1. MULTI 命令之后，Redis 会将后续所有命令暂存于事务队列中，返回 QUEUED。
  2. EXEC 执行时，Redis 会依次执行队列中的命令，并返回每个命令的结果。
  3. 整个过程是原子的，即在 EXEC 执行期间，其他客户端无法插入命令干扰。

✅ 注意：Redis 事务不支持回滚。如果某个命令执行失败（比如语法错误），其他命令仍然会执行。只有在 EXEC 执行前，命令本身无效时，才会被拒绝。

事务中的错误处理

Redis 事务的错误处理方式与其他数据库不同，理解这一点至关重要。

场景一：命令语法错误

MULTI
SET key1 value1
INCR key2  # 错误：INCR 需要数字类型，如果 key2 不存在或不是数字，会报错
EXEC

结果：

(error) ERR value is not an integer or out of range

此时，EXEC 会返回错误，但注意：之前执行成功的命令不会被撤销。也就是说，SET key1 value1 已经生效，无法回滚。

⚠️ 这是 Redis 事务与传统数据库最显著的区别：它不提供回滚机制。

场景二：运行时错误（如类型不匹配）

SET user:score "abc"
MULTI
INCR user:score  # 运行时错误，字符串不能自增
EXEC

结果：

(error) ERR value is not an integer or out of range

同样，INCR 失败，但 SET 操作已经生效。

如何避免这类问题？

  • 在事务前先检查数据类型。
  • 使用 WATCH 命令监听键的变化，如果在事务执行前键被修改，事务将被取消。

使用 WATCH 实现乐观锁

在并发场景中，如果多个客户端同时读取同一个键并尝试修改，就可能出现“脏写”问题。Redis 提供了 WATCH 命令来实现乐观锁机制。

示例：模拟用户余额扣减

WATCH user:balance:1001

GET user:balance:1001

MULTI

DECRBY user:balance:1001 100

RPUSH user:log:1001 "deduct 100"

EXEC

如果在 EXEC 执行前，有其他客户端修改了 user:balance:1001，EXEC 将返回 nil，表示事务失败。此时客户端可以重试。

关键点：

  • WATCH 监听的键在事务执行前被修改，事务自动失败。
  • 事务失败后，需要重新获取最新值，重新执行 WATCH + MULTI + EXEC 流程。

这就像你在抢购商品时，系统会先锁定库存，如果别人先抢了，你的订单就失败，需要重新尝试。

Redis 事务的实际应用场景

1. 购物车结算

在电商系统中，用户提交订单时，需要从库存中扣减商品数量，并记录订单信息。

MULTI
DECRBY stock:product:1001 5
RPUSH order:1001:items "product:1001"
HSET order:1001:info user_id 1001 total 499.99
EXEC

这个事务确保了：商品库存减少、订单项添加、订单详情写入，三者要么全部成功，要么全部失败（实际中失败后可重试）。

2. 积分系统更新

用户完成任务后，需要增加积分并记录日志。

WATCH user:score:1001

MULTI
INCRBY user:score:1001 100
RPUSH user:log:1001 "earned 100 points"
EXEC

使用 WATCH 保证积分更新的原子性，防止并发修改导致数据丢失。

Redis 事务与 Lua 脚本对比

虽然 Redis 事务能保证命令的顺序执行，但它不支持复杂逻辑判断。当需要更复杂的条件判断时，可以使用 Lua 脚本。

特性 Redis 事务 Lua 脚本
原子性 命令按序执行，但不支持回滚 完全原子，脚本执行期间不可中断
错误处理 失败不影响已执行命令 脚本中出错则整个脚本失败
复杂逻辑 无法判断条件 支持 if/else、循环等逻辑
性能 轻量，适合简单操作 稍重，适合复杂业务

✅ 推荐：简单操作用事务，复杂逻辑用 Lua 脚本。

常见误区与最佳实践

❌ 误区一：认为 Redis 事务支持回滚

Redis 事务不支持回滚。一旦 EXEC 执行，成功执行的命令无法撤销。

❌ 误区二：忽略 WATCH 的作用

在高并发场景下，不使用 WATCH 会导致数据竞争。必须结合 WATCH 实现乐观锁。

✅ 最佳实践建议：

  1. 事务只用于简单、可预测的命令组合。
  2. 使用 WATCH 监听关键键，防止并发冲突。
  3. 事务失败后，应实现重试逻辑。
  4. 避免在事务中执行耗时操作，防止阻塞其他客户端。
  5. 使用 EXEC 前，确保所有命令语法正确。

总结

Redis 事务虽然不像传统数据库那样支持完整的 ACID 特性，但它在缓存场景下提供了轻量级的原子性保障。通过 MULTI、EXEC 和 DISCARD，我们可以将多个操作打包执行，提升数据一致性。

结合 WATCH，还能实现乐观锁，有效应对并发问题。虽然它没有回滚机制，但通过合理的设计和重试策略，依然能构建出稳定可靠的系统。

对于初学者来说，掌握 Redis 事务是理解缓存与数据一致性的重要一步。而中级开发者则应深入掌握其与 Lua 脚本、Watch 机制的协同使用，从而在真实项目中灵活应对复杂业务需求。

记住：Redis 事务不是万能的，但它是一个强大而高效的工具，用得好，能极大提升系统稳定性与开发效率。