当前位置：首页 > 问答 > 正文

红色事务里Redis请求那些事儿，怎么理解和处理redis的事务操作

帖慧艳
问答
2025-12-31 22:26:29
2

（引用来源：Redis官方文档关于事务的章节，以及《Redis设计与实现》一书中对事务的讨论）

说起Redis里的事务,咱们可以把它想象成去超市买东西，平时你买一件商品，扫一次码付一次钱，这就是单个命令，但有时候你需要买一大堆东西，比如为周末聚会做准备，你希望把购物车里的所有商品一次性结账，而不是每拿一个就去收银台排一次队，Redis的事务就是为了实现这种“一次性打包处理”的需求。

Redis的事务操作很简单,主要靠三个命令：MULTI, EXEC, 和 DISCARD，你可以这样理解：

MULTI：就像是你对Redis说：“嗨，我接下来要开始往购物车里放东西了，你先帮我记着，先别急着算钱。” 当你输入MULTI命令后，Redis返回OK，表示它进入了“事务模式”，从此之后，你发的所有命令（比如SET name "张三", INCR count, SADD friends "李四"）都不会被立即执行，而是被Redis一个一个地排进一个队列里，你会收到QUEUED的回复，意思是“命令已排队”。
EXEC：等你把所有要执行的命令都“加入购物车”后，你就输入EXEC命令，这相当于你推着满满的购物车到收银台说：“好了，我买完了，现在一起结账吧！” 这时，Redis会把你刚才队列里的所有命令，按照顺序一次性全部执行掉，执行完后，它会返回一个列表，里面按顺序装着每个命令的执行结果。
DISCARD：这个命令就像是，你把东西放进购物车后，突然改变主意不想买了，或者发现钱没带够，于是你对Redis说：“算了算了，刚才选的我都不要了，清空购物车吧。” 输入DISCARD后，之前用MULTI开启的事务队列会被清空，并且退出事务模式，就像什么都没发生过一样。

怎么理解Redis事务的特点呢？

这里有几个非常关键的点,和咱们熟悉的数据库事务（比如MySQL）不太一样，理解了这些才能真正用好它。

第一,Redis事务没有“回滚”能力，这是最最重要的一点，在传统数据库里，如果事务中有一个命令失败了（比如违反了唯一约束），整个事务会被回滚，所有操作都撤销，但Redis不是这样，在Redis事务中，命令入队时Redis只会做简单的语法检查，如果语法错了，整个事务都无法执行（比如你输错了命令名），如果语法没错，运行时出错（比如你用HINCRBY命令去操作一个字符串类型的键），那么只有那个出错的命令会失败，队列里的其他命令依然会继续执行，而且不会自动撤销，Redis官方认为，大多数命令错误都是编程错误，应该在开发阶段就发现，而不是靠运行时回滚，回滚功能会让Redis变得复杂，违背其设计哲学，你得接受这个设定：事务中的命令要么都执行，但错了的自己负责，没有“后悔药”。

红色事务里Redis请求那些事儿，怎么理解和处理redis的事务操作

第二,事务在执行期间不会被其他客户端打断，这是Redis事务的核心价值，当Redis开始执行EXEC时，它会按顺序、不间断地执行队列中的所有命令，在执行EXEC的整个过程中，不会有其他客户端的命令插队进来，这保证了这些命令作为一个孤立的单元来运行，避免了竞争条件，你的事务里包含“读取键A的值，然后根据这个值设置键B”，你能确保在读取和设置之间，没有别人修改过A，这通过“串行化执行”实现了简单的隔离性。

第三,乐观锁的玩法：WATCH，你的事务能否成功执行，取决于某个键的值在你准备事务的过程中有没有被别的客户端改动，你想实现一个“如果账户余额大于100，就扣除100”的功能，你可能会这样写：

WATCH balance // 开始监视balance这个键
value = GET balance
if value > 100:
    MULTI
    DECRBY balance 100
    EXEC
else:
    UNWATCH // 或者DISCARD

WATCH命令就像是给你的关键数据（比如balance）贴上一个“监视贴”，在MULTI之前你WATCH它，如果在MULTI开始后到EXEC执行前的这段时间里，有其他的客户端修改了balance的值，那么当你执行EXEC时，Redis会发现这个“监视贴”被动过了，它会拒绝执行整个事务，返回nil，这样你就知道有人捷足先登了，你需要重新尝试这个逻辑，这就像你看中了一件打折商品，你把它拿在手里（WATCH），然后去决定要不要买（组织MULTI事务），如果在你去收银台（EXEC）的路上，别人从你手里抢走了商品（修改了数据），那收银员会告诉你交易失败，这是一种乐观锁，它假设冲突不常发生，发生时再重试。

总结一下怎么处理Redis事务：