说句得罪人的话Redis 事务可能是整个 Redis 生态里被误解最深的特性。不少人面试前背了一堆 MULTI、EXEC、WATCH以为拿到了和 MySQL 事务等价的东西结果一上生产就傻眼——命令报错不回滚、中途崩溃留半截数据、想拿它做分布式锁又发现压根不是那么回事。我最早也被这个事务名字坑过一次后来把官方文档、源码和线上行为对照着梳理了一遍才算真正搞明白它的边界在哪。这篇文章不绕弯子直接把 Redis 事务的设计思路、执行流程、常见误用和排查手段讲透也会讲清楚它和 Lua 脚本、Pipeline、分布式锁之间的关系。适合后端开发、运维同学也适合那些正在准备 Redis 面试、被Redis 事务能不能保证原子性这类问题卡住的人。1. 理解 Redis 事务的设计思路与核心机制1.1 Redis 事务是什么四个命令组成的轻量批处理Redis 事务由 MULTI、EXEC、DISCARD、WATCH 四个命令支撑。MULTI 开启一个事务之后的命令不会立即执行而是被 Redis 服务器放进一个命令队列EXEC 触发队列里的命令依次执行DISCARD 则是放弃整个队列WATCH 可以在事务开启前监控一个或多个 key如果这些 key 在执行前被其他客户端修改整个事务会被取消。这个机制的本质是命令打包和顺序执行。Redis 保证的是一个事务里的命令在执行期间不会被其他客户端的命令插进来也就是连续执行、中间无穿插。它没有传统数据库的隔离级别、没有回滚日志、也没有锁等待。与其说 Redis 事务是数据库事务不如说它更像一个批量执行器。我习惯用一个银行柜台的类比普通模式下你每提交一次请求柜员就处理一次MULTI 是先让你填一张单据单据上按顺序列了好几个操作然后一次性交给柜员柜员按顺序办完中间不接待别人。但注意柜员只承诺按顺序办完并没有承诺如果第三个操作失败前两个操作会被撤销。理解这一点Redis 事务的很多反直觉行为就都能解释了。1.2 单线程模型决定了事务的天花板为什么 Redis 事务会被设计成这副模样根源在 Redis 的执行模型。虽然 Redis 6.0 之后引入了多线程 IO 来处理网络读写但真正执行命令逻辑的仍然是单个主线程也就是说所有命令在一个线程里排队跑。这个模型有个巨大收益数据库层面根本不存在两个客户端同时写一个 key的并发冲突问题因为同一时刻只有一条命令在改数据。既然没有真正的并发写传统数据库里那些复杂机制——锁粒度控制、隔离级别、MVCC 快照、回滚段——在 Redis 这里就全部不需要了。Redis 把精力集中在如何让一批命令连续执行完上用最简单的方式实现了它想要的原子性不被打断。但也正是这个模型堵死了回滚这条路。当一条命令在执行时报错Redis 没有回滚日志可查没有原数据快照可恢复它只能选择继续往下执行。这是设计者的明确取舍为了极致的简单和高性能主动放弃回滚这种重量级机制。你可以说它有遗憾但不能说它是 bug。搞清楚这一点再回头看网上那些Redis 事务保证原子性的说法你就知道它们只说对了一半。严格讲Redis 事务保证的是执行过程不被打断不保证全部成功或全部失败。只有在命令都合法、服务器不崩溃的理想前提下它才表现出完整的原子性。1.3 拿 ACID 衡量 Redis 事务差距在哪这个对比很有用面试和实际选型都用得上。我直接放一张表维度传统关系型事务Redis 事务原子性全部成功或全部失败失败可回滚入队阶段的错误会让整个事务拒绝执行执行阶段的错误只影响当前命令不回滚一致性通过约束、回滚等手段保证类型错误时不保证业务语义一致但不会产生结构非法的数据隔离性提供多种隔离级别命令执行期间无穿插但不对中间结果做快照也没有隔离级别概念持久性靠 WAL 日志和刷盘策略事务本身不额外保证持久性依赖 RDB/AOF 配置没开持久化就可能丢这张表基本就是 Redis 事务和普通 DBA 认知最大的冲突点。平时聊 ACID大家默认对标 MySQL但 Redis 事务只占了个事务的名头内核完全是另一套逻辑。我建议你把它当成一个独立的工具来理解而不是拿传统事务的尺子去量它。2. 核心细节解析执行流程、错误分类与边界行为2.1 事务的完整生命周期入队、执行、清理一个 Redis 事务从开始到结束严格经历三个阶段。入队阶段客户端发送 MULTI连接进入事务状态。此后发来的命令不会执行而是逐条进入命令队列。这里有个细节即便是 SET、GET 这种本来立即返回结果的命令此时也会固定返回 QUEUED意思是我知道命令来了先排队。执行阶段客户端发送 EXECRedis 把队列里的命令按顺序逐条执行并把所有结果打包成数组返回。清理阶段EXEC 执行完毕连接自动退出事务状态。如果此时客户端断线事务状态也会被清空。还有一个中途出口DISCARD。只要 EXEC 还没发出去DISCARD 就可以把整个命令队列清空相当于把填好的单据撕了。这个命令很容易被忽略但它很有用——比如客户端获取到最新数据后发现条件不满足不想执行这批命令直接 DISCARD 就好干净利落。需要注意的是如果客户端在事务状态中断开连接Redis 也会自动丢弃这个事务的所有命令。你不会遇到服务端留下半截未执行事务的情况前提是你还没发出 EXEC。2.2 两类错误分别在两个时点暴露这是大多数人在 Redis 事务上报错后一脸懵的根本原因。事务里的错误分成两类暴露的时点完全不同。第一类是入队阶段的错误。典型场景是命令语法拼错、命令名不存在、参数个数不对。这类错误在命令往队列里放的时候就会被发现Redis 直接返回错误并且整个事务在 EXEC 时会被拒绝执行返回 EXECABORT。相当于一票否决入队时有一条命令不合法整个事务都不跑。第二类是执行阶段的错误。典型场景是给一个字符串类型的 key 执行 LPUSH、对一个不存在的 key 执行 SORT、触发内存上限 OOM、执行了受保护的命令等。这类错误在入队阶段根本看不出来只有真正执行到那条命令才会爆发。Redis 的处理方式是当前命令报错但队列里剩下的命令继续执行。这就是网上吵翻天的部分原子性的真正来源。我用一个最直观的例子展示第二类错误127.0.0.1:6379 MULTI OK 127.0.0.1:6379 SET score 100 QUEUED 127.0.0.1:6379 LPUSH score list QUEUED 127.0.0.1:6379 SET remark ok QUEUED 127.0.0.1:6379 EXEC 1) OK 2) WRONGTYPE Operation against a key holding the wrong kind of value 3) OKLPUSH 报错了但前后两个 SET 都成功了。很多新手看到这个结果第一反应是Redis 事务是假的吧其实不是假的只是它的容错策略和你预期的不一样。如果业务要求执行阶段一条出错后面全部不执行裸事务做不到必须上 Lua 脚本在脚本里做类型检查、条件判断遇到异常自己控制返回从逻辑上模拟出全做或全不做的效果。2.3 DISCARD 与 WATCH事务的两个关键辅助DISCARD 前面说了就是丢弃命令队列没什么复杂的。真正有含金量的是 WATCH。WATCH 必须在 MULTI 之前使用用来监控一个或多个 key。如果在 WATCH 之后、EXEC 之前被监控的 key 被别的客户端修改了EXEC 会返回空结果整个队列不执行。这是一个乐观锁不提前锁住资源只在提交时校验版本。经典的读改写场景长这样WATCH balance GET balance MULTI DECR balance 50 EXEC两个客户端同时对 balance 做先读后写时WATCH 能保证只有一个能提交成功。失败的客户端 EXEC 返回 nil业务代码决定重试。在多实例、多进程的架构下这个机制仍然有效而且不依赖任何第三方组件。WATCH 有几个容易忽略的细节它只在当前连接上生效连接断开就失效EXEC 执行后无论成功失败WATCH 状态都会被清掉。如果你要做循环重试每次都需要重新 WATCH。另外WATCH 只能监控 key 是否被修改不能监控 key 的某个字段是否变化要监控 Hash 字段得自己想办法通常是把相关字段合并成一个字符串 key或者直接改用 Lua 脚本。2.4 事务在主从复制和持久化场景里的表现主从场景下Redis 不会把 MULTI/EXEC 原样传递给从库。主库执行完事务后会把事务内命令的执行结果或改写后的命令逐条同步给从库最终从库状态与主库一致。这里没有主从回滚的概念主库执行阶段的错误不会回滚从库也不会因为某条命令失败而回退。两边都会留下部分执行的最终状态。持久化场景更值得关注。开启 AOF 后事务内的命令会按实际执行顺序写入 AOF 文件。如果服务器在事务执行一半时崩溃重启后 AOF 里可能只保留了前几条命令数据停留在半截事务的状态。Redis 不会为事务生成任何补偿日志所以这个窗口是真实存在的。关键业务的应对思路有两个一是把多条命令合并成一条 Lua 脚本因为脚本在 Redis 内部要么完整执行、要么不执行脚本层面的异常会导致整体返回错误但不会写入部分命令可以把崩溃窗口压缩到最小二是业务侧接受至少一次的最终一致性用对账任务去修正半截状态。根据我的经验后一种方案在生产环境更常见因为纯粹靠 Redis 特性很难覆盖所有异常分支。3. 实操过程从入队到执行手写一个可复现的 Redis 事务3.1 快速准备一个本地 Redis 环境最省事的办法是用 Docker 拉一个官方镜像docker run -d --name redis-test -p 6379:6379 redis:7 docker exec -it redis-test redis-cli不想用 Docker 也没关系直接去 Redis 官网下载对应平台的二进制包解压就行。Windows 上可以用官方支持的 Memurai或者装在 WSL 的 Linux 发行版里命令本身没有差异。下面所有演示在 Redis 5.0 以上版本都能跑通。我用一个电商下单的例子来串场扣减库存、创建订单、追加一条操作日志。三个操作要求按顺序执行不能被其他请求插队。3.2 完整命令演示事务的四种玩法第一种普通事务把三步打包MULTI DECR stock:10001 SET order:88801 created LPUSH order:88801:log create at 2025-01-01 10:00:00 EXEC执行后三个命令按顺序完成中间不会有其他客户端的命令插进来。但注意如果 DECR 成功、SET 失败DECR 不会回滚。所以这种方式适合顺序执行且后失败不影响前面结果的场景。第二种WATCH 加事务处理读改写WATCH stock:10001 GET stock:10001 MULTI DECR stock:10001 EXECEXEC 返回 nil 就说明 stock:10001 在 WATCH 之后被人动过需要重新 GET、重新 WATCH、重试。这就是乐观锁的完整循环。不过要提醒一句扣库存这种场景如果能用单条命令直接 DECR 并且用返回值判断是否小于 0其实根本不需要事务。只有当你还需要同时读取其他 key 做复杂判断时WATCH 才真正派得上用场。第三种Lua 脚本替代事务这是我在生产环境最推荐的做法local stock redis.call(GET, KEYS[1]) if tonumber(stock) 0 then return -1 end redis.call(DECR, KEYS[1]) redis.call(SET, KEYS[2], created) return 1通过 EVAL 调用redis-cli EVAL $(cat script.lua) 2 stock:10001 order:88801Lua 脚本在 Redis 里的执行同样具备不被打断的特性而且支持条件判断和流程控制。遇到异常可以主动 return不会像裸事务那样留下半截执行的结果。所以凡是你发现自己要在事务前后写 if/else或者需要读-判断-写连在一起建议直接切到 Lua。第四种事务和 Pipeline 组合。事务本身会带来额外的网络往返MULTI 一次、EXEC 一次。如果事务里有大量命令可以把从 MULTI 到 EXEC 的整个交互放在一个 Pipeline 里发送减少 RTT。注意 Pipeline 本身没有原子性它解决的只是网络开销问题。3.3 三种常见的误用场景误用一把事务当分布式锁。有人用 MULTI 包裹检查 key 是否存在 设置 value 设置过期时间试图实现一个带判断的加锁操作。这本身就不必要——加锁用 SET key value NX EX seconds 一条命令就完成原子操作了根本不需要事务。事务解决的是多条命令的顺序执行不是资源互斥。误用二在事务里做需要回滚的写操作。典型是转账场景A 减钱、B 加钱如果 B 的类型错误导致加钱失败A 的钱已经扣掉了。这种场景必须用 Lua 脚本在脚本里先校验两个 key 的类型和余额任何一个异常直接返回错误从逻辑上保证全做或全不做。裸事务在这里只会制造新的对账噩梦。误用三在事务里做条件判断和循环。Redis 事务就是一个命令队列没有控制流能力。带上 if/else、循环的逻辑要么用 Lua 脚本要么在客户端拼装命令。记住一句话需要智能决策的时候别用事务硬扛。4. 常见问题与排查技巧实录4.1 为什么我的事务只执行了一半这是线上被问得最多的一个问题。直接原因就是执行阶段的错误不会回滚前面的命令已经生效后面的命令可能正常执行完也可能继续报错。排查思路我整理成了一套固定动作用 redis-cli 的 monitor 命令抓取事务执行前后的命令流确认事务区间内是否真的没有插入命令。看 EXEC 返回的数组定位是哪个位置出现了 WRONGTYPE、OOM、ERR。如果是 WRONGTYPE大概率是同一个 key 被不同业务方用了不同类型说明 key 命名和类型管理出了问题。如果是 OOM检查 maxmemory 和内存淘汰策略事务里大概率混入了在内存饱和时不该执行的写命令。我自己踩过一个很深的坑定时同步任务把一批数据写入 Redis里面既有字符串字段也有 Hash 字段结果另一个业务方误把某个 Hash key 覆盖成了字符串。同步任务跑到那条数据时 LPUSH 直接报错但前面几条已经写进去了后面几条继续执行线上数据变成一半新一半旧排查了整整一个下午。后来把所有批量同步改成 Lua 脚本在脚本里先做 TYPE 检查再写入才彻底解决。4.2 用事务做库存扣减为什么还是超卖原因在于事务不会替你重新读取数据。你先 GET 库存再开事务 DECR这个 GET 的结果在执行前可能已经过期了事务本身不会校验。传统数据库事务可以通过锁和快照保证读到的值就是当前值Redis 事务没有这个能力。要真正解决超卖两种主流姿势一种是 WATCH 加事务加重试。WATCH 库存 keyGET 判断库存MULTI 里 DECR如果 EXEC 返回 nil 就重试。这种方式能保证不超卖但并发高时重试率会很高性能一般。另一种更推荐直接用 Lua 脚本把判断 扣减合并if tonumber(redis.call(GET, KEYS[1])) 0 then return redis.call(DECR, KEYS[1]) else return -1 end这个脚本天然满足高并发扣库存不需要 WATCH不需要事务。所以面试题里问Redis 扣库存怎么保证不超卖正确答案不是事务而是 Lua 脚本或者单条 DECR 配合返回值判断。这个区分很关键我见过太多人在面试时栽在这一问上。4.3 事务、Lua、Pipeline 到底怎么选我整理了一张选型表生产环境可以直接参考方案支持条件判断支持回滚语义网络往返适用场景事务 MULTI/EXEC不支持不支持MULTI 和 EXEC 各一次命令按顺序执行、防止穿插WATCH 事务部分依赖客户端重试不支持多出 WATCH 与重试往返读改写、乐观锁Lua 脚本支持支持脚本内部控制一次往返原子读-判断-写Pipeline不支持不支持一次往返但无原子性批量写入、性能优化给新手一个不出错的建议优先用 Pipeline 加 Lua事务只在明确面试需要、或者确实只要求一堆无关联命令按序执行的场景才用。分布式锁场景严格走 SET NX 加过期时间加 Lua 释放锁的路线不要试图用事务去模拟锁。4.4 事务在缓存和分布式锁场景里的真实定位缓存更新有一个经典操作先删缓存、再更新数据库、再回填缓存。不少人习惯把这三步塞进 Redis 事务。但这里有个逻辑漏洞——数据库更新不在 Redis 里Redis 事务只能保证 Redis 内部这三条命令连续执行管不了数据库那一环。整个链路的原子性仍然无从谈起只能用最终一致性方案兜底。分布式锁场景最常见的坑是加锁后执行多步业务锁提前过期其他客户端拿到锁后并发执行。这类问题事务帮不上忙需要的是锁的续期机制和释放锁时的 Lua 校验确认是自己加的锁才释放。顺便理清一个混淆点能不能用 Redis 事务实现分布式锁不能。但可以用 Lua 脚本实现加锁 业务 解锁的原子执行这正是事务的合理替代者。至于缓存穿透、缓存击穿这些话题和事务的关系不大主要靠布隆过滤器、空值缓存、热点 key 保护去解决。不过有一个细节值得留意回填缓存时如果有多条数据要一起写用事务一次回填会比逐个 SET 更合理至少避免中间状态被别人读到半个数据集合。5. 最后我在生产环境里的真实经验5.1 我的选型习惯事务并不是第一选择生产环境里我用 Redis 事务的次数远少于 Lua 脚本更远少于 Pipeline。原因很简单需要顺序执行、不需要回滚、没有条件判断的场景确实存在但往往单条命令就能解决一旦出现读改写、条件判断、回滚需求事务就给不了而这些 Lua 几乎全都能给。事务对我来说更大的价值是帮助理解 Redis 对原子性的边界把握以及面试时把 ACID 的四个维度讲清楚。踩过几次坑之后我形成一套固定套路涉及多个 key 的原子操作第一反应写 Lua需要把一批无关命令依次执行第二选择用事务只做批量写、不要求原子性直接用 Pipeline。分布式锁永远是 SET NX 过期时间 Lua 释放。这套组合拳用下来因为半截事务导致的数据错乱基本清零了。5.2 调试事务的一个小技巧最后送一个能帮你在现场快速判断问题的技巧调试 Redis 事务时同时打开两个终端一个跑 monitor一个执行你的事务命令。仔细观察事务执行窗口内有没有出现其他客户端的命令。如果看到插入了那你用的多半不是事务而是把几条命令分开发了。真正的事务从 EXEC 发出到返回值拿到中间 Redis 绝对不会执行别人的命令。这一点用 monitor 一眼就能验证比背十遍文档都管用。另外建议给所有开启事务的连接设置合理的客户端超时时间。因为事务持续期间这个连接不能执行其他命令如果一个客户端开了事务又迟迟不发 EXEC其他复用该连接的请求就会全部阻塞。生产环境里我见过因为这类悬挂事务导致整个连接池被拖垮的案例处理办法很简单事务只开短连接要么加 watchdog 主动超时关闭要么在客户端代码里用 try-finally 强制 DISCARD。Redis 本身没有事务超时机制这个保护只能由调用方自己加。