Redis里那些你可能没注意到的事务控制技巧和实用玩法分享

在Redis的世界里，一提“事务”，很多人第一反应就是MULTI和EXEC这对基本命令，这没错，但如果你只停留在“开启事务-打包命令-执行”这个层面，可能会错过一些更精细的控制和巧妙的用法，今天我们就来聊聊那些你可能没太留意,但非常实用的事务技巧。

不是所有“失败”都回滚——认清Redis事务的原子性

首先要明确一个关键点，这和很多人从数据库那里带来的直觉不同，Redis事务的原子性指的是：事务中的所有命令会作为一个隔离的、不可中断的序列一起执行。它不具备“回滚”能力。

这是什么意思呢？比如你在MULTI后输入了三个命令：

1. SET key1 value1
2. INCR key2 （假设key2本来是个字符串,无法增加）
3. SET key3 value3

当你执行EXEC时，Redis并不会因为第二个命令出错，而撤销第一个和第三个命令，第一个SET已经成功了，第三个也会照常执行，错误只会体现在EXEC返回的结果列表里,对应第二个命令的位置会是一个错误信息。

来源参考： 在Redis官方文档关于事务的说明中明确指出，Redis事务在执行期间不会回滚,而是会继续执行后续命令。

理解了这一点，你就能明白，事务内的命令语法错误（比如命令名拼错）会在入队时就被Redis检测并拒绝，整个事务都无法执行；而运行时错误（比如对字符串做INCR）则不会影响其他命令。 确保入队命令的正确性和潜在的数据类型匹配,是你需要自己负责的。

乐观锁的实战：用WATCH代替沉重的悲观锁

这是Redis事务最精彩的部分之一。WATCH命令可以轻松实现一种“乐观锁”的机制，它的工作方式很像代码版本管理里的“检出-修改-提交”流程。

实用玩法场景： 假设你要实现一个“秒杀”功能，库存stock初始为10，如果没有WATCH,你的代码可能是：

1. GET stock 得到当前值,比如10。
2. 判断如果大于0，则执行 DECR stock。

但在高并发下，两个请求可能同时读到stock=10，都执行了DECR，最终库存可能变成8而不是9,出现了超卖。

用WATCH可以优雅地解决：

WATCH stock // 开始监视stock这个键
stock_count = GET stock // 读取当前值
if stock_count > 0:
    MULTI
    DECR stock
    result = EXEC // 这里是关键！

核心技巧在于EXEC的执行时刻： 如果在WATCH之后到EXEC之前，有任何其他客户端修改了stock的值（比如另一个请求已经把它减到了0），那么你当前这个事务的EXEC命令将返回nil，表示执行失败，你的程序收到这个失败信号后，可以选择重试整个逻辑（重新WATCH，重新判断）,或者直接返回失败。

这样一来，你不需要用真正的锁去阻塞其他请求，而是通过“检查版本”的方式，只在数据没有被意外改动时才提交变更，极大地提升了并发性能，这是一种非常“Redis风格”的轻量级并发控制。

放弃事务与命令入队检查

事务不是一旦开启就必须执行的。DISCARD命令可以清空事务队列并退出事务状态,这个看似简单的命令在某些场景下很有用。

你在MULTI后放入了一系列命令，但在放命令的过程中，根据某个计算或判断，发现后续操作已经没有意义了，这时，与其浪费资源执行一个无效的事务，不如直接DISCARD掉,提前结束。

在MULTI之后，每个命令入队时，Redis只会进行基本的语法检查（比如命令是否存在，参数个数对不对），如果语法错误，当你执行EXEC时，整个事务都会被拒绝，所有命令都不执行，你可以利用这一点，在开发阶段提前发现一些低级错误，但切记,前面提到的运行时错误是检查不出来的。

事务与管道（Pipeline）的结合，追求极致性能

事务（MULTI/EXEC）本身会把命令打包，减少网络往返时间（RTT），而管道（Pipeline）是另一个减少RTT的常用技术,它们俩可以强强联合。

实用玩法： 当你需要一次性执行大量命令，并且其中一些逻辑上需要保证原子性时，可以这样做：在同一个管道中，先发送MULTI命令，然后发送所有要执行的命令（包括那些不需要事务的普通命令和需要事务保障的命令），最后发送EXEC命令。

虽然非事务命令在管道中也会被依次执行，但这样做的好处是，你只需要一次网络写入和一次读取，就能完成混合操作，最大程度地利用网络带宽，只是需要注意，你要自己解析返回结果，区分出哪些是普通命令的回复，哪些是EXEC返回的事务块回复。

脚本化事务：Lua脚本是更强大的选择

对于复杂的事务逻辑，Redis更推荐使用Lua脚本。你可以把Lua脚本看作是一种更强大、更灵活的事务形式。

来源参考： Redis官方文档建议，对于复杂情况，使用Lua脚本比使用MULTI/EXEC更简单,并且减少了竞争条件的风险。

因为Lua脚本在执行时是原子性的（整个脚本在执行期间不会被其他命令打断），而且它天生就具备了“WATCH”的特性——脚本在执行前会检查所有用到的KEYS，如果任何KEY被其他客户端修改，脚本就不会执行，更重要的是，你可以在脚本内进行复杂的逻辑判断、循环计算,这是普通事务命令队列无法做到的。

上面的秒杀例子,用Lua脚本写就是一行的事：

local current = redis.call('GET', KEYS[1])
if tonumber(current) > 0 then
    return redis.call('DECR', KEYS[1])
else
    return -1
end

然后通过EVAL命令一次性发送执行，它既保证了原子性，又避免了额外的网络往返,代码也更清晰。

跳出“事务就是MULTI/EXEC”的固定思维，你会发现Redis提供了更丰富的工具集，理解其“不回滚”的特性是基础；掌握WATCH实现乐观锁是处理并发问题的利器；在必要时用DISCARD优雅退出；将事务与管道结合追求性能极致；而对于复杂逻辑，Lua脚本往往是更优解，这些技巧能让你在面对不同场景时,更加游刃有余。