事务队列 怎样区分排队错误与执行错误

Redis 事务里最容易误判的一点，是把 QUEUED 当成“业务执行成功”。实际上，MULTI 之后命令先进入事务队列，真正执行要等到 EXEC；而 EXEC 返回的数组，还可能包含某一条命令自己的运行时错误。排查时要先看错误出现在入队前、入队时，还是执行后。

官方文档：https://redis.io/docs/latest/

一句话判断：命令没有进入队列，是排队错误；进入队列但某项在 EXEC 后报错，是执行错误；EXEC 返回空值，则优先检查 WATCH 监视键是否被修改。

先把事务队列和工作队列分开

这里的“事务队列”指 Redis MULTI 后暂存命令的队列，不是把业务消息放进去等待消费者处理的工作队列。两者的成功信号完全不同：

因此，日志里出现“入队成功”不能直接推出“任务完成”。如果你的程序同时使用 MULTI 和 BRPOP，建议分别记录事务 ID、消息 ID 和处理状态，避免把 Redis 命令队列与业务工作队列混成一个状态机。

识别 EXEC 前的排队错误

MULTI 成功后，Redis 不立即执行后续命令，而是把命令放进当前连接的事务队列。正常入队时客户端会看到 QUEUED。如果命令名、参数数量等在入队阶段就无法接受，错误发生在 EXEC 之前；较新的 Redis 会拒绝这组事务并在 EXEC 时体现为事务中止。

MULTI
# 进入事务模式，后面的命令暂不执行
SET job:1 pending
# 参数完整时只会返回 QUEUED
LPUSH job:queue job:1
# EXEC 才触发前面两条命令
EXEC

这类错误的处理重点是“不要重试一个已经无法入队的请求”。先记录原始命令和客户端返回，再修正命令名、参数或连接状态。若日志只有 QUEUED，它只能证明命令已经排队，不能证明键值已经改变。

识别 EXEC 后的执行错误

执行阶段的问题要看 EXEC 返回数组的每一个位置。Redis 会按入队顺序返回每条命令的回复；某一条命令可能因为键类型不匹配等原因返回错误，但其他命令不因此自动回滚。Redis 事务提供串行执行，不提供传统数据库式回滚。

SET task:state ready
# 先准备一个字符串键
MULTI
# 这两条命令都会排队
INCR task:state
SET task:done 1
# 第一项可能是 WRONGTYPE，第二项仍可能成功
EXEC

客户端应把返回数组按下标映射回原命令，并把“事务已执行但部分命令失败”作为独立状态。对于不能接受部分成功的场景，提交前先确认键类型，或改用 Lua 脚本把业务条件与写入放在同一个原子判断里；不要仅凭 EXEC 请求没有网络异常就标记全部成功。

WATCH 取消与工作队列确认要单独处理

WATCH 是乐观锁条件：被监视的键在 EXEC 前被其他客户端修改时，事务不会执行，EXEC 返回空值。这个空值不是“某条命令返回 NULL”，而是整组事务因为条件不满足而取消。应用层通常重新读取最新值、重新计算，再决定是否重试，并设置有限次数和退避。

WATCH stock:sku-1
# 读取后在本地计算，期间其他客户端可能修改该键
MULTI
DECRBY stock:sku-1 1
EXEC
# 返回空值表示 WATCH 条件失败，不是 DECRBY 的普通结果

如果业务队列使用 Redis List，LPUSH 与 BRPOP 可以组成先进先出的生产者/消费者模型；BRPOP 等待消息时超时返回空值，和 WATCH 的事务取消不是一回事。如果需要消费者确认与待处理记录，Redis Streams 的 XREADGROUP 配合 XACK 更适合：读取后未确认的消息仍会出现在 Pending 语义中，不能在业务尚未完成时提前确认。

回归检查与迁移清单

1. 把客户端日志拆成三段：命令入队回复、EXEC 总体回复、业务处理回复。
2. 为每个返回数组位置保留原命令名，单独统计 WRONGTYPE 等执行错误。
3. 把 EXEC 空值标为 WATCH 冲突候选，使用重新读取和有限重试，不把它当作成功。
4. 列表队列记录“取出”和“处理完成”两个状态；Streams 在处理完成后再发送 XACK。
5. 升级 Redis 客户端或服务端后，回归命令参数错误、运行时类型错误、WATCH 冲突和消费者未确认四个场景。

相关问题

为什么看到 QUEUED 仍不能确认成功？ 因为它只表示命令暂存，真正结果要等 EXEC。

EXEC 返回数组里有错误时会自动回滚吗？ 不会，Redis 事务没有传统回滚语义，需要在设计上避免或补偿部分成功。