Redis MULTI 命令错误 怎样处理

我在排查 Redis 事务时，最容易误判的一点是把所有 MULTI 报错都当成“事务失败，重新执行一次”。实际上要先看错误出现在哪个阶段：命令没有成功入队时，Redis 会拒绝这组事务；命令已经入队、到 EXEC 才发现数据类型不对时，其他命令仍可能继续执行。处理顺序一旦混淆，就容易重复写入或把固定的代码错误变成无休止重试。

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

Redis MULTI 的错误为什么要分两个阶段

MULTI 本身只负责进入事务状态，后续命令先排队，直到 EXEC 才真正执行。正常排队时客户端看到的是 QUEUED，这不是业务结果，而是“命令已进入队列”的确认。

如果命令名不存在、参数数量不对，Redis 可以在排队阶段发现问题。此时坏命令不会进入队列；在较新的 Redis 中，累积阶段出现这类错误后，继续调用 EXEC 会得到事务中止类错误，整组排队命令不会被执行。这个错误应该回到代码里修，不应该直接重试。

# 进入事务后，先观察每个命令是否真的返回 QUEUED
MULTI
# 这里只是示意错误：INCR 需要一个 key，不接受多余参数
INCR account:points extra
# 发现排队错误后清空当前连接上的事务状态
DISCARD

另一类错误要到执行时才能知道。例如某个 key 实际存的是字符串，却把它交给列表命令。命令语法没有问题，所以它可以先返回 QUEUED；到 EXEC 读取真实数据类型后，才在返回数组中出现 WRONGTYPE。

遇到 EXECABORT 或排队失败时怎样清理

排队阶段报错后，先停止向同一个事务继续追加命令。客户端若仍保持这条连接，应调用 DISCARD 退出事务状态；如果客户端库已经把连接标记为异常并准备回收，则按库的连接管理规则释放它。关键不是“多发一次 EXEC”，而是让下一次请求从普通连接状态开始。

可以把处理逻辑写成三步：记录原始错误和命令位置；清理事务队列；修复命令构造或参数来源。比如用户输入被拼成 Redis 命令时，应该在应用层完成类型和参数校验，不能指望 Redis 的重试把错误输入变正确。

# 这是一个清理顺序示例，不代表必须使用交互式客户端
MULTI
# 业务命令全部返回 QUEUED 后才能继续等待 EXEC
SET profile:42:display_name "Lin"
# 如果前面的命令返回错误，立即放弃本次事务
DISCARD

还有一个连接边界值得记住：在调用 EXEC 前连接断开，事务中的操作不会被执行；一旦 EXEC 已经发出，就不能再把它当成“肯定没有写入”的请求来重试。网络超时只说明客户端没有及时收到结果，不等同于服务端没有处理。

EXEC 返回 WRONGTYPE 时不要假设自动回滚

Redis 事务保证命令按顺序、连续地执行，但不是数据库式的全量回滚。假设第一条命令成功，第二条命令因为 key 类型不匹配失败，第三条命令仍可能执行。客户端必须按 EXEC 返回数组的顺序逐项读取，并把错误项和对应命令关联起来。

# 先准备一个类型明确的 key，下面的队列故意混入一个可能出错的操作
SET order:42 "text"
MULTI
# 这条命令会排队，但执行时可能触发 WRONGTYPE
LPUSH order:42 "item"
# 这条命令与上一条独立，仍可能在 EXEC 中执行
SET order:42:updated "yes"
EXEC

处理这类结果时，记录事务编号、命令序号、key 和 Redis 返回的错误类型；不要把 WRONGTYPE 当作暂时网络故障。修复方向通常是统一 key 命名和数据模型、在写入前确认类型，或让同一业务对象只使用一种 Redis 数据结构。

WATCH 冲突和固定命令错误要分开重试

WATCH 是乐观锁机制：如果被观察的 key 在 WATCH 到 EXEC 之间发生变化，EXEC 会放弃这次事务，客户端通常收到空结果。此时可以重新读取最新值，再在有限次数内组装事务。

但 EXECABORT、未知命令和 WRONGTYPE 不属于同一种“竞争冲突”。前者需要修代码，后者需要修数据或命令与数据结构的对应关系。把它们都放进统一重试循环，会放大日志和请求量，也可能让一个确定性错误持续占用连接。

常见问题

MULTI 后每条命令都返回 QUEUED，是不是已经执行成功？

不是。QUEUED 只说明命令进入队列，真正结果要等 EXEC 返回；执行阶段仍可能出现类型或数值错误。

EXEC 里有一条命令报错，Redis 会回滚前面的写入吗？

不会把普通执行期错误当作全量回滚。应按返回数组逐项处理，并为需要一致性的业务设计补偿或更合适的数据模型。

什么时候适合重试 MULTI？

WATCH 冲突或明确可恢复的连接问题，才可能进入受限重试；固定的语法、参数、类型错误应先修复原因，不能盲目重发。