Redis事务到底有多神奇？那些你可能没注意到的特性和用法揭秘

Redis事务到底有多神奇？那些你可能没注意到的特性和用法揭秘 引用自知乎专栏“Redis深度历险”、官方文档以及技术博客“酷壳-CoolShell”的相关讨论）

很多人第一次接触Redis事务时，可能会从其他数据库（比如MySQL）的经验出发，产生一些误解，最经典的误解就是：“Redis事务能不能在中间步骤失败时回滚？” 答案是：能，但方式和你想的不太一样,这正是Redis事务神奇又独特的地方。

它不是传统事务：没有隔离性和回滚的“陷阱”

在MySQL这类关系型数据库里，事务有ACID特性，其中的I（Isolation隔离性）意味着事务执行过程中，不会被其他事务干扰，但Redis是单线程执行命令的！这个核心架构决定了它的“事务”本质是另一种玩法。

Redis通过MULTI、EXEC命令来实现事务，你把一系列命令写在MULTI和EXEC之间，Redis会将这些命令排队，当你发出EXEC命令时，它会一次性、按顺序执行所有排队命令，在这个过程中，不会有其他客户端的命令插队，所以它天生就具备了一种“隔离”的效果,但这和MySQL基于锁或多版本控制的隔离级别是两回事。

更反直觉的是它的“回滚”机制，官方文档明确指出了一个关键点：Redis事务在命令执行时才会报错，并且不会回滚已经执行成功的命令。

这是什么意思呢？举个例子,假设你在一个事务里写了三条命令：

1. set name Alice （正确命令）
2. sadd fruit apple （正确命令）
3. incrby money 100 （错误命令：如果money这个key存的不是数字,这条命令会失败）

你用EXEC执行后，Redis会告诉你结果：第一条成功（返回OK），第二条成功（返回1），第三条失败（返回错误信息），你会发现，前两条命令已经生效了，name被设置成了Alice，集合里也添加了apple,只有第三条命令没执行成功。

为什么会这样？知乎专栏“Redis深度历险”里解释得很清楚：Redis追求简单和性能，支持回滚需要记录操作前的状态，这对于内存数据库来说代价太高，所以它的设计哲学是，错误应该在开发阶段就被发现，而不是等到生产环境靠回滚来补救，这种“弱原子性”要求开发者对自己的命令有十足的把握。

真正神奇的特性：“乐观锁” Watch

如果说上面这个特性有点让人失望，那WATCH命令就是Redis事务中最闪亮、最实用的神奇功能了，它实现了类似“乐观锁”的机制。

想象一个经典场景：你的Redis里存着一个用户的余额（balance:user1 = 100），现在有两个客户端A和B,都想把这个余额减去50。

• 没有WATCH的悲剧：

  1. 客户端A读取balance:user1,得到100。
  2. 客户端B也读取balance:user1,得到100。
  3. 客户端A计算 100-50=50，然后执行 set balance:user1 50。
  4. 客户端B也计算 100-50=50，然后执行 set balance:user1 50。 结果，用户的余额变成了50，而不是正确的0,因为B的操作覆盖了A的操作。

• 使用WATCH的完美流程：

  1. 客户端A和B都使用 WATCH balance:user1 命令,监视这个key。
  2. 它们各自开启事务（MULTI）。
  3. 它们各自在事务中执行 set balance:user1 50。
  4. 当客户端A先执行EXEC时，Redis会检查balance:user1这个key自从被A监视后，是否被其他命令（包括B的EXEC）修改过，发现没有，于是A的事务成功执行,余额变为50。
  5. 当客户端B再执行EXEC时，Redis同样进行检查，发现balance:user1已经被A修改过了！B的整个事务会被直接驳回，返回nil,表示执行失败。
  6. 客户端B可以重新读取新的余额（50）,然后重试整个逻辑。

技术博客“酷壳-CoolShell”曾高度评价这个设计，认为它用一种非常轻量级的方式解决了并发竞争问题，非常适合用在秒杀、抢购等需要保证数据最终一致性的场景，你不需要像用数据库那样加沉重的悲观锁，只需要在关键数据上打个“标记”（WATCH）,让Redis帮你盯着就行。

容易被忽略的用法：事务内的命令并非“与世隔绝”

另一个有趣的细节是，在MULTI开启后、EXEC执行前，你输入的命令并不会立即执行，所以你也得不到结果，所有结果要等EXEC后一起返回，这带来一个限制：你无法在事务中根据前一条命令的结果来决定下一条命令是什么。

Redis脚本（Lua Script）完美地弥补了这个缺陷，你可以把整个复杂的逻辑写在一个Lua脚本里，然后一次性发给Redis执行，脚本在执行时同样是原子性的，而且中途可以处理逻辑判断，功能比事务更强大，在很多高级用法中,Lua脚本已经逐渐成为替代复杂事务的首选。

总结一下

Redis事务的神奇之处在于它“不像事务的事务”，它简单直接，通过命令打包一次性执行来保证一批操作的原子性；它坦诚地放弃了复杂的回滚，却提供了一个极其巧妙的“乐观锁”（WATCH）来解决并发问题，理解它的这些独特设计，而不是生搬硬套传统数据库的概念，才能真正发挥出Redis高性能、高并发的优势，下次当你需要考虑一组Redis操作的原子性时，不妨先想想，是需要简单的命令打包，还是需要配上WATCH来防并发,或者干脆用一个Lua脚本搞定所有。