企业官网建设流程全解析

上个月帮人排查一个线上超卖问题，秒杀接口用的是Redis事务，压力一上来库存还是扣成了负数。代码逻辑很常见：先查库存、判断大于0、再扣减，外面套了MULTI/EXEC。我扫了一眼就问：那条GET查库存的命令，也在事务队列里吗？对方当场愣了。这就是Redis事务最容易被误解的地方——它在EXEC到达的那一刻，才真正执行队列里的命令，而“读库存”发生在MULTI之前，等于你拿着旧值在做判断。类似的情况我还见过不少：有人把它当MySQL事务的回滚机制用，有人在Spring的RedisTemplate里面没绑同一个连接导致WATCH失效，还有人把“批量执行”和“原子性”混成一件事。这篇文章想把Redis事务一次讲透，覆盖五个命令的用法、底层队列机制、和MySQL事务的本质差异、生产环境实操心法，以及面试里怎么把它答出层次。适合正在学Redis的开发者、写过Redis但没细究过事务细节的人，也适合准备面试的同学。

1. 把“事务”二字掰开：Redis事务能保证什么，不能保证什么

1.1 一句话定义：命令的打包连续执行

官方文档对Redis事务的说法是：MULTI、EXEC、DISCARD、WATCH这几个命令，让客户端可以在一个步骤里执行一组命令，并且这些命令会按顺序执行，不会被其他客户端的命令打断。注意这里的关键词是“打包连续执行”，不是数据库教科书上那套“回滚、快照、隔离级别、持久化”。

我更喜欢用一个比喻来理解它：Redis事务就像一个快餐柜台，你在一个窗口一次性点了三份餐，后厨按顺序做，中间不会去接别的单子。但这个过程中如果第二份餐做砸了，后厨不会把第一份已经递出去的餐收回来重做；只有你在点单时发现菜名本身不存在，收银员才会整单不接。这个比喻基本把Redis事务的脾气说清楚了：执行顺序有保证，回滚不存在，点单时的非法命令会整单拒绝。

1.2 ACID四项逐条核对：哪些是真的，哪些只有一半

我把传统数据库的ACID概念逐条套到Redis事务上，很多误解立刻就现形了。

原子性那条是面试重灾区。严格意义上，Redis事务不满足数据库事务的原子性标准——它承诺的是“执行过程不被打断”，而不是“失败可回滚”。如果事务里三条命令，第二条运行时抛了类型错误，第一条照样生效。后面我会专门用命令演示这个场景。

隔离性也要分清楚。Redis单线程执行命令，EXEC处理事务队列时，其他客户端的命令必须排队等待，所以事务内的命令之间不会穿插外部命令。但这不是MySQL那种隔离级别，并且从MULTI到EXEC之间，其他客户端完全可以在你监控的key上做修改，数据之间没有“未提交可见性”一说，所有写入一旦执行就立刻对全局生效。

1.3 最常见的四个错误认知

第一个误区：“事务里的命令要么全执行，要么全不执行”。这只说对了一半。入队阶段如果出现语法错误，确实会触发EXECABORT导致整体放弃；但到了执行阶段，某条命令运行时出错并不会让整个事务回滚或中止。

第二个误区：“写错了能回滚”。直接否决，Redis没有ROLLBACK命令，也没有对应的回滚机制。DISCARD只是清空尚未执行的队列，和回滚完全是两码事。

第三个误区：“开了事务之后，其他客户端读不到我修改的数据”。这一条错得最离谱。Redis数据修改是即时生效的，不存在事务未提交状态。多客户端并发执行事务时，读到的都是当前内存里的最新值，不会因为你“在事务中”而看到旧快照。

第四个误区：“Redis事务能帮我解决分布式事务”。它是单实例或单slot层面的工具，跨服务、跨数据库的分布式事务一致性，它扛不住，需要另找方案。

2. 五个命令搭起完整骨架：MULTI/EXEC/DISCARD/WATCH/UNWATCH

2.1 最基础的流程：MULTI + EXEC

先看最朴素的用法，跟着Redis命令行敲一次基本就记住了。

127.0.0.1:6379> MULTI OK 127.0.0.1:6379> SET article:1001:view 100 QUEUED 127.0.0.1:6379> INCR article:1001:view QUEUED 127.0.0.1:6379> EXEC 1) OK 2) (integer) 101

在MULTI之后，客户端进入事务状态，后续发送的命令服务端不会立即执行，而是返回QUEUED表示命令已经进入事务队列。直到EXEC发到服务端，才按入队顺序逐个执行，并把每个命令的结果放在一个数组里一起返回。

这里有个容易被忽略的点：队列中的命令在QUEUED阶段不会做真正的数据检查，比如key的类型是否正确、内存是否够用，这些都要到EXEC执行时才会暴露。入队时服务端只检查命令是否存在、参数个数是否合法。

单条命令在事务里被“压着不执行”，意味着你的客户端有两条网络往返：MULTI发出后，后续命令其实已经到服务端了，只是排队而已。所以事务天然有一点pipeline的效果——多条命令的最终执行集中在一次EXEC，减少了往返次数。

2.2 中途反悔用DISCARD

如果MULTI之后你改了主意，不想执行队列里的命令了，执行DISCARD：

127.0.0.1:6379> MULTI OK 127.0.0.1:6379> SET name tony QUEUED 127.0.0.1:6379> DISCARD OK

DISCARD会清空当前事务队列，退出事务状态。重申一次，这不是回滚，因为事务根本还没执行，没有数据被修改过，自然不存在“恢复原状”的必要。

2.3 WATCH：真正的并发保护能力

MULTI/EXEC本身解决的是“一组命令连续执行不被插入”的问题，但它解决不了“先读后写”这种依赖前置状态的并发问题。假设你在MULTI之前读了库存等于10，做判断后想DECR扣减，可在你MULTI到EXEC之间的几百毫秒里，另一个客户端已经把库存扣到了5，你手里的10就是旧数据。WATCH就是为这个场景准备的。

WATCH的使用原则是：必须在MULTI之前执行，它可以监听一个或多个key。如果被监听的key在WATCH之后、EXEC之前被任何客户端修改了，那么EXEC执行时会直接放弃整个事务队列，返回nil。

127.0.0.1:6379> WATCH stock:1001 OK 127.0.0.1:6379> GET stock:1001 "10" 127.0.0.1:6379> MULTI OK 127.0.0.1:6379> DECR stock:1001 QUEUED 127.0.0.1:6379> EXEC (nil)

上面这个模拟场景里，在WATCH和EXEC之间我假设另一个客户端把stock:1001改成了别的值，所以EXEC直接返回了nil，事务队列里的DECR没有执行。客户端收到nil之后，正确的姿势是重新走一遍“读库存、判断、再扣减”的流程，也就是重试。

源码层面的实现是：每个被WATCH的key会记录在watched_keys结构里，当Redis执行任何可能修改该key的命令时，会调用touchWatchedKey，把对应的客户端打上CLIENT_DIRTY_CAS标记。EXEC时客户端检查这个标记，只要被改过就直接拒绝执行事务。这也是为什么“WATCH必须和MULTI/EXEC在同一个连接上”的原因，客户端标识是跟着连接走的。

还有一个UNWATCH命令，作用是手动解除所有WATCH监控。在事务执行完EXEC、或者DISCARD之后，监控也会自动解除，所以UNWATCH用的场景很少，一般是在你WATCH之后、MULTI之前发现数据已经没必要保护了，主动解除监控。

3. 队列机制与错误处理：事务执行阶段的三种异常分支

3.1 两个时间点：入队阶段和执行阶段

搞清楚事务里的命令什么时候可能出错，是避免线上事故的关键。Redis事务的命令处理有两个时间节点：

入队阶段：MULTI之后，命令逐条发到服务端，服务端只做基础校验——命令名认不认识、参数个数对不对。校验通过就返回QUEUED，不通过会返回错误信息。

执行阶段：EXEC到达服务端之后，才真正逐条执行队列里的命令。此时才会遇到类型不匹配、key不存在的前提下执行某种操作、内存不足这类运行期问题。

理解“错误发生的时间点不同，处理语义完全不同”，是掌握Redis事务错误处理的核心。下面三个分支，建议对照命令行亲手敲一遍。

3.2 分支一：入队阶段语法错误，触发EXECABORT整体放弃

127.0.0.1:6379> MULTI OK 127.0.0.1:6379> SET (error) ERR wrong number of arguments for 'set' command 127.0.0.1:6379> SET name tony QUEUED 127.0.0.1:6379> EXEC (error) EXECABORT Transaction discarded because of previous errors.

从Redis 2.6.5开始，只要入队阶段出现任何错误，EXEC就会拒绝执行，返回EXECABORT。这是Redis事务里最接近“全有或全无”语义的场景，因为队列里的命令一条都不会执行。

注意一个细节：这里不是说“有语法错误的命令不执行，其他的照常执行”，而是整个事务被放弃。所以当你的业务在入队阶段能提前发现命令不合法时，相当于获得了一道前置保护。利用好这一点，尽量把外部输入参数的校验放在进入事务之前，可以把很多错误掐死在入队阶段。

3.3 分支二：运行期类型错误，造成部分成功

这是最坑的一个分支，也是面试必考点。

127.0.0.1:6379> MULTI OK 127.0.0.1:6379> SET name tony QUEUED 127.0.0.1:6379> LPUSH name john QUEUED 127.0.0.1:6379> EXEC 1) OK 2) (error) WRONGTYPE Operation against a key holding the wrong kind of value

事务里第一条SET执行成功，第二条LPUSH对string类型的name执行，直接报WRONGTYPE。可关键在于：事务没有因此终止，也没有回滚，SET的结果被完整保留。这就是Redis事务“部分成功”的经典例子。

很多人在代码里只判断“调用事务的方法有没有抛异常”，根本不检查EXEC返回的结果数组里的每一项，这是极其危险的。上面这个场景下，业务可能以为第二个操作也失败了，但实际上第一个操作已经生效，数据处于“只改了一半”的状态。

3.4 分支三：WATCH冲突，EXEC返回nil

前面已经演示过，WATCH监听的key在EXEC前被改动时，EXEC返回nil。分支三和分支二的区别在于：返回nil时事务队列里的命令一条都没执行，数据没有发生任何变化，你需要做的就是重试整个读-判断-写流程。

三种分支对比如下：

3.5 客户端代码里怎么处理这三种结果

以Spring Data Redis为例，正确姿势是用SessionCallback保证所有操作在同一个连接上。

List<Object> results = redisTemplate.execute(new SessionCallback<List<Object>>() { @Override public List<Object> execute(RedisOperations operations) { operations.watch("stock:1001"); Object stock = operations.opsForValue().get("stock:1001"); if (stock == null || Integer.parseInt(stock.toString()) <= 0) { operations.unwatch(); return null; } operations.multi(); operations.opsForValue().decrement("stock:1001"); return operations.exec(); } });

拿到results之后，如果是null，说明是WATCH冲突，走重试；如果非null，一定要遍历results里的每一个元素，逐个检查是否有异常信息。很多业务代码只看results是不是null，忽略了内部项的异常判断，结果在“部分成功”时傻傻地当作全部成功处理，下游数据就错乱了。

4. 别拿MySQL事务硬套：隔离级别、回滚、持久化的真实差异

4.1 同名事务，不同基因：一张表看懂差别

“Redis事务”和“MySQL事务”虽然都叫事务，底子完全不同。MySQL事务的核心是回滚日志、锁、MVCC、隔离级别，而Redis事务的核心是单线程命令排队和乐观锁标记。

很多程序员习惯拿MySQL的思路套Redis，最典型的就是问“Redis事务的隔离级别是什么”。直接回答：没有隔离级别。因为Redis数据没有“未提交”状态，每个命令执行后就立即对全局可见，不存在脏读、不可重复读、幻读这些概念的空间。

4.2 Redis事务的“隔离性”到底怎么理解

Redis单线程执行模型意味着，在同一时刻只有一条命令在执行。当一个EXEC触发事务队列执行时，队列里的命令会连续执行完，这期间其他客户端的命令全部排队等待。所以你可以说，事务命令之间是严格串行的，这就是它的隔离性来源。

但请把这个隔离性的范围理解清楚：它只覆盖“EXEC执行命令队列那一刻”到“队列执行完为止”。从MULTI到EXEC之间的时间窗口完全不设防，其他客户端可以任意修改数据。Redis 6.0之后引入了多线程网络IO，但命令执行依然是单线程，所以事务的上述行为没有改变。

并发场景下，两个客户端都执行事务，Redis的服务端会依次处理两个EXEC，每个EXEC的命令队列内部不会被插入。但两个事务各自“读库存、判断、扣减”的读和写之间，依然存在覆盖风险，这正是WATCH存在的意义。

4.3 Redis放弃回滚，是设计取舍而非缺陷

官方文档里有一句话很值得琢磨：事务失败通常是由编程错误导致的，比如错误的数据类型、key不存在时操作list，这些错误在开发阶段就应当暴露。让数据库为程序员的错误做回滚，对Redis这样追求极致简单和高性能的系统来说得不偿失。

这个取舍的逻辑是：回滚需要维护undo信息，会带来额外的内存和复杂度；Redis的设计哲学是“命令执行本身极快，错误尽量前置”。如果你需要真正意义上的“要么全做，要么全不做”，可以考虑使用Lua脚本，它能在脚本内部做更严格的逻辑控制，但已经把操作写进内存的数据同样不会自动回滚。所以无论事务还是脚本，业务侧都要对部分失败有所准备。

5. 实战落地：扣库存、批量写入、缓存更新的正确姿势

5.1 秒杀库存：WATCH + 事务实现乐观锁

最典型的适用场景是秒杀扣库存，核心需求是“不能超卖”，也就是多个并发请求同时扣减时，最终库存不能变成负数。用WATCH + MULTI/EXEC写出来大概是这个样子：

int retryCount = 3; while (retryCount-- > 0) { List<Object> results = redisTemplate.execute((RedisOperations ops) -> { ops.watch("stock:1001"); String stockStr = (String) ops.opsForValue().get("stock:1001"); if (stockStr == null || Integer.parseInt(stockStr) <= 0) { ops.unwatch(); return null; } ops.multi(); ops.opsForValue().decrement("stock:1001"); return ops.exec(); }); if (results != null) { // 扣减成功，继续后续业务 break; } // results为null表示WATCH检测到冲突，循环重试 }

这段代码的关键在于：WATCH和MULTI/EXEC必须都在同一个连接上，而且只能通过redisTemplate.execute(SessionCallback)这种方式包裹，不能拆成两个方法各取连接。WATCH冲突返回null时，业务需要立即重试，否则请求直接失败。我习惯设置2到3次重试上限，超过后走降级，比如“当前库存紧张”的提示，避免无限重试拖垮服务端。

还要注意，parseInt计算库存和业务判断都在客户端完成，这样一来“读-判断-写”三个动作的网络开销还在，只是多了一层并发保护。如果同一接口的QPS非常高，这种方式还是不够快，这时候就切换到Lua脚本，把判断逻辑挪到服务端。

5.2 批量写入：用事务换取瞬时一致性

另一个常见场景是多个key需要同时更新，比如用户资料里同时改name、age、tags三个字段。如果不做任何保护，另一个客户端可能读到“name更新了但age还没更新”的中间状态。用事务包一层，EXEC执行时三个HSET会连续发生，中间不会被外部命令插入，其他客户端读到的要么是更新前的旧值，要么是更新后的新值，少了一个一个key慢慢变的中间态。

127.0.0.1:6379> MULTI QUEUED 127.0.0.1:6379> HSET user:1001 name tony QUEUED 127.0.0.1:6379> HSET user:1001 age 28 QUEUED 127.0.0.1:6379> HSET user:1001 tags vip QUEUED 127.0.0.1:6379> EXEC 1) (integer) 1 2) (integer) 1 3) (integer) 1

这个场景的收益是“多个key的更新在瞬间内完成”，不是持久化的强一致，但对缓存场景足够用了。配合pipeline思想，事务还能减少网络往返，批量写入性能也不错。

5.3 缓存与数据库的一致性：别指望Redis事务兜底

很多同学会问：既然Redis事务能保证多个key的原子更新，那我用它来保证“删除缓存”和“更新缓存标记”的一致性，是不是就能解决缓存和数据库的数据同步问题？

答案是不够。缓存与数据库是两个独立的存储系统，一个Redis事务只能约束Redis内部的命令执行顺序，约束不了MySQL的提交或回滚。数据库的事务提交之后，Redis这边可能刚好在事务执行中，双方没有统一的提交点，这是典型的分布式事务问题，不是Redis本地事务能覆盖的。正确的思路还是走延迟双删、消息队列、或分布式事务方案，Redis事务在这里最多只能充当其中一环。

5.4 什么时候该换Lua脚本

事务虽然好用，但“读判断写”这种逻辑在事务里要经历多轮网络往返，而且WATCH重试的成本也不低。如果同一个操作里既有复杂的逻辑判断，又希望减少网络开销，Lua脚本是更好的选择。脚本在服务端整体执行，执行期间其他客户端命令也不会插入，天然有原子性。

扣库存用Lua脚本写出来是这样：

local stock = tonumber(redis.call('GET', KEYS[1])) if not stock or stock <= 0 then return -1 end return redis.call('DECR', KEYS[1])

用Java调用时不需要WATCH，也不需要重试循环，脚本的返回值-1表示库存不足，返回正数就是扣减后的库存。对比可见，逻辑简单的并发保护用事务足够，逻辑复杂或对性能敏感的场景优先Lua。无依赖的批量命令，直接pipeline就行，没必要上事务。

6. 我在生产环境踩过的坑与排查链路

6.1 WATCH失效：连接上下文不一致

我之前排查过一个偶发超卖问题，代码里明明用了WATCH，压测却还是出现库存扣成负数。第一次看代码，WATCH、MULTI、EXEC都在方法里，觉得没问题。深挖后发现，项目里有人手动从连接工厂拿了两个连接，一个执行WATCH，另一个执行MULTI/EXEC。WATCH的监控绑定在客户端连接上，换了连接就完全失效，等于裸奔。

排查这种问题的思路是：第一，确认WATCH和MULTI/EXEC是否在同一个RedisConnection上；第二，如果用了Spring Data Redis，尽量全部塞进SessionCallback，让框架替你绑定连接；第三，别在事务中间穿插任何会切换连接的操作，比如重新获取连接、订阅消息等。连接一旦换，所有事务语义全部归零。

6.2 忽略EXEC结果列表里的异常项

另一个事故是交易对账平不了。代码里用Redis事务批量更新了两个key，然后只判断了exec结果是否为null。压测时遇到底层类型变化，其中一个key的写入命令报WRONGTYPE，exec返回的结果列表里第二条是异常对象，但外层方法没有抛异常，业务照样往下走。数据错位之后又因为没有回滚机制，只能靠人工补偿脚本去修。

从那以后我给自己定了一条规矩：事务代码里，拿到exec返回的结果列表一定要遍历，凡是列表项为异常类型的都要单独记录并触发补偿。判断事务成功，不是“方法没抛异常”，而是“返回列表里每一项都正常”。这条在代码评审里也是必检项。

6.3 集群模式下永远绕不开的CROSSSLOT

Redis Cluster下使用事务有个硬性约束：事务队列中所有命令涉及的key必须映射到同一个slot，否则执行时报CROSSSLOT错误。我在一个多key事务上踩过这个坑，当时业务key写得比较随意，比如user:1001:name和user:1001:age，从CRC16算法看它们可能落在不同slot上。

解决办法是用hash tag让多个key强制归到同一个slot，也就是把key写成user:{1001}:name和user:{1001}:age这种形式，花括号内的内容参与hash计算，两个key就落同一slot了。这个设计在单机Redis下也不会有副作用，所以从第一天设计key的时候就把hash tag写进去，是最省事的习惯。真要遇到跨slot又无法改造的场景，基本说明这个功能不该用Redis实现，该考虑其他存储了。

6.4 事务“成功”了，数据却丢了

还有一次，业务反馈说Redis事务执行成功，但版本升级重启后，部分事务结果没了。排查链路走到最后发现，Redis实例既没开AOF也没开RDB，所有写入只存在于内存。事务成功代表命令已经在内存里执行完，但如果进程在持久化动作之前崩溃，内存数据直接归零，事务结果自然跟着没了。

就算是开启了AOF，默认的everysec刷盘策略下，崩溃时最多丢最后一秒的写入；即使改成always，事务命令真正落到磁盘之前崩溃，仍然存在极小概率丢失。所以结论要清醒：Redis事务从来不给持久性承诺，如果你把不能丢的数据放在Redis里，那就是架构设计的问题了。核心账务、订单状态这类强持久数据，必须放到数据库里。

7. 面试中被追问Redis事务时，先讲清楚边界再回答

7.1 面试官的高频问题清单

面试中围绕Redis事务的问题，来来去去就是这几个：

1. Redis事务和MySQL事务的区别是什么？
2. Redis事务能保证原子性吗？
3. WATCH是怎么实现的？
4. 为什么Redis不支持回滚？
5. Redis事务和Lua脚本应该怎么选？
6. Redis事务在集群里有什么限制？

前两个是必问题，后面几个是追问。想要不被问倒，核心是把“Redis事务的边界”讲清楚，而不是背一句“事务保证原子性”。

7.2 把“能保证原子性吗”答出一个层次感

如果面试官问“Redis事务能保证原子性吗”，直接答“能”或者“不能”都很被动，因为这个问题本身考察的是你对工具边界的认知。我建议按下面这条线答：

先定义原子性。传统数据库的原子性意味着“要么全部生效，要么全部不生效应，失败时能回滚”。从这个标准看，Redis事务不满足。它只保证两点：一是EXEC执行事务队列时，队列中的命令连续执行、不被其他客户端命令插入；二是入队阶段的语法错误会触发EXECABORT，整体放弃执行。但运行期错误不会触发回滚，已执行命令保留，会出现部分成功。所以严格说，Redis事务提供的是“执行过程的原子性”而不是“数据结果的原子性”。

然后补充WATCH的作用。如果业务需要“读判断写”这种依赖旧值的场景，WATCH能在EXEC前检测key是否被修改，一旦被修改就放弃执行，返回nil给客户端，让客户端重试。这就是它解决并发覆盖的方式。做到这一步，你已经把原理、边界、并发控制全部覆盖了，面试官基本没有再追的余地。

7.3 面试官其实在借事务考核三个能力

把这些问题剥开来看，面试官想考察的其实是三件事：第一，你懂不懂Redis单线程执行模型和它与MySQL的本质区别；第二，你写业务代码时会不会检查异常结果，懂不懂“部分成功”的补偿处理；第三，你能不能根据场景选型，知道什么情况用事务、什么情况换Lua脚本、什么情况压根不该用Redis。

所以面试的时候不要只背概念，最好举一个自己做过的真实例子，比如秒杀扣库存时用WATCH和事务解决超卖，或者上线前发现集群CROSSSLOT问题改key设计。有场景、有踩坑、有修复方案的回答，比任何标准答案都更有说服力。

最后说一个我自己的习惯：现在接到任何涉及Redis并发一致性的需求，我第一反应不是上MULTI/EXEC，而是先问自己这段“读-判断-写”逻辑能不能压缩成一条原子命令，或者改成一段Lua脚本。压不了、又确实需要防并发覆盖时，才用事务加WATCH。这个顺序倒过来，我踩过不止一次坑。你要是正在排查线上类似问题，优先检查连接上下文、exec返回结果、集群slot、持久化配置这四个方向，大概率答案就在其中之一。