Redis事务的使用小结

作者：袖梨 2026-06-25

前言：

在日常开发中，很多开发者要么不知道 Redis 有事务，要么以为它和 MySQL 的事务是一回事。两者差挺远的，搞混了线上容易出问题。这篇文章把核心机制、坑点、乐观锁和面试常问的几个问题串一遍。

Redis 事务到底是什么

把多条命令塞进一个队列，到点了按顺序一口气执行完。执行过程中其他客户端插不进来。就这四个命令：

- MULTI — 开始攒命令
- EXEC — 队列里的命令全部执行
- DISCARD — 不玩了，清空队列
- WATCH — 盯住一个或多个 key，EXEC 之前如果有人动过，事务自动取消

上手：转账的例子

A 账户扣 100，B 加 100。先看看正常流程：

127.0.0.1:6379> SET account:A 500OK127.0.0.1:6379> SET account:B 200OK127.0.0.1:6379> MULTIOK127.0.0.1:6379> DECRBY account:A 100QUEUED127.0.0.1:6379> INCRBY account:B 100QUEUED127.0.0.1:6379> EXEC1) (integer) 4002) (integer) 300

MULTI 之后每条命令都返回 QUEUED，说明在排队。EXEC 一执行，结果按入队顺序返回。

想反悔的话：

127.0.0.1:6379> MULTIOK127.0.0.1:6379> SET k1 v1QUEUED127.0.0.1:6379> DISCARDOK

队列清空，什么都没发生。

最容易踩的坑：错误处理

Redis 事务里的错误分两种，处理逻辑完全不同，搞混了线上真的会出事。

第一种：语法错误（入队时就发现了）

命令拼错了、参数不对，Redis 当场报错，EXEC 的时候整个事务直接取消：

127.0.0.1:6379> MULTIOK127.0.0.1:6379> SET k1 v1QUEUED127.0.0.1:6379> NOTACMD(error) ERR unknown command 'NOTACMD'127.0.0.1:6379> SET k2 v2QUEUED127.0.0.1:6379> EXEC(error) EXECABORT Transaction discarded because of previous errors.

k1 和 k2 都没写进去。这种还好，至少是"全有或全无"。

第二种：运行时错误（执行了才发现不对）

语法没问题，执行时栽了——比如对字符串做 INCR。Redis 会跳过那条出错的命令，其余的照常执行，已经执行的不会回滚：

127.0.0.1:6379> SET k1 "hello"OK127.0.0.1:6379> MULTIOK127.0.0.1:6379> SET k1 "world"QUEUED127.0.0.1:6379> INCR k1QUEUED127.0.0.1:6379> SET k2 v2QUEUED127.0.0.1:6379> EXEC1) OK2) (error) ERR value is not an integer or out of range3) OK

k1 变成了 world，k2 也写进去了。只有 INCR 那条挂了。这就是 Redis 事务和 MySQL 事务最要命的区别——Redis 事务不支持回滚。

不支持回滚是故意的

很多人第一次知道这个会觉得很坑。说实话我第一次也这么觉得。

但 Redis 官方的逻辑是：运行时错误是程序员的 bug——你对 String 类型的 key 做 INCR，这应该在测试阶段就发现。为此让 Redis 支持回滚，意味着每次操作前要保存旧数据、出错时逐条恢复，这对一个追求极简和高性能的东西来说太重了。

所以用 Redis 事务，你得自己保证命令是对的。别把它当 MySQL 用。

WATCH：乐观锁

MULTI/EXEC 有个盲区：如果事务里的命令依赖某个 key 当前的值，而这个值在 MULTI 之后、EXEC 之前被别的客户端改了，事务照样正常执行，结果就出错了。

比如库存剩 1，两个客户端同时读到 1，都觉得自己能下单，两个都执行了 DECR，库存直接变 -1。

WATCH 解决的就是这个。

怎么用

127.0.0.1:6379> SET stock 1OK127.0.0.1:6379> WATCH stockOK127.0.0.1:6379> GET stock"1"127.0.0.1:6379> MULTIOK127.0.0.1:6379> DECR stockQUEUED127.0.0.1:6379> EXEC1) (integer) 0

被别人抢先改了

另一个客户端在 WATCH 之后、EXEC 之前动了 stock，你的 EXEC 返回 nil，一条命令都不会执行：

127.0.0.1:6379> EXEC(nil)

收到 nil 就说明事务没执行。重读数据、重新判断、再试一次，这就是乐观锁的标准套路。

几个细节：
- EXEC 执行后（不管成败），WATCH 自动解除
- DISCARD 也会解除所有 WATCH
- 想主动解除可以执行 UNWATCH

ACID 四个维度怎么看

你可以这样说：

- 原子性 — 有条件的。队列命令按顺序执行、不被插入，这部分是原子的。但运行出错不回头，不是严格意义的原子性。

- 一致性 — 语法错误全取消，不会脏写。

- 隔离性 — EXEC 前队列里的命令对其他客户端不可见，执行不被打断。

- 持久性 — 看你开了什么。AOF + appendfsync always 就有持久性；RDB 或 AOF everysec 就有可能丢数据。

Redis 事务 vs 关系型数据库

对比项	Redis事务	关系型数据库事务
回滚支持	不支持	支持
运行时错误处理	跳过出错命令，继续执行	回滚整个事务
隔离级别	执行期间不被打断	多级隔离级别可选
持久性	取决于持久化配置	默认持久化
使用场景	简单批量操作	复杂业务逻辑，强一致性要求