Redis BLMOVE 阻塞队列时如何设计超时后的回滚

Redis BLMOVE 的阻塞超时本身不需要回滚：当 source 列表为空并且 timeout 到期时，命令返回 nil（RESP2）或 null（RESP3），既没有从源列表弹出元素，也没有向目标列表压入元素。真正要设计补偿的，是任务已经从 queue:ready 原子转移到 queue:processing，但 worker 在业务处理或确认前失败的情况。

官方地址：https://redis.io/docs/latest/commands/blmove/

判断回滚的关键不是看 BLMOVE 是否设置了超时，而是看它有没有返回任务。没有返回任务就没有状态变化；返回任务后未完成业务，才需要补偿。

先把 BLMOVE 的返回语义分清

BLMOVE 的语法是 BLMOVE source destination wherefrom whereto timeout，在 source 有元素时会以 O(1) 复杂度完成列表间移动；source 为空时才进入阻塞等待。timeout 使用秒，可以是小数，设为 0 表示持续等待。

因此 worker 至少要区分三类结果：

用两个列表保留“已领取但未确认”

如果直接用 RPOP queue:ready，worker 一旦在业务调用前崩溃，任务就只剩客户端内存中的副本。更稳妥的最小模型是生产者用 LPUSH 写入 ready，消费者用 BLMOVE 从右侧取出，再把任务放入 processing 的左侧：

# 生产者把任务放到左侧，消费者从右侧取出以保持 FIFO
redis-cli LPUSH queue:ready job-1001

# 最多等待 3 秒；返回空值表示本次没有任务，不做回滚
redis-cli BLMOVE queue:ready queue:processing RIGHT LEFT 3

这一步的价值是“领取”和“登记处理中”由 Redis 的一个命令完成。任务 ID 要保持唯一，processing 中不要只放可能重复的业务名称，否则后续 LREM 可能确认错元素。

把 ack 放在业务成功之后

BLMOVE 返回任务只代表领取成功，不代表订单写入、邮件发送或外部 API 调用已经成功。worker 应先完成业务动作，再从 processing 删除对应的唯一任务 ID：

# 只有业务副作用成功后才确认，count=1 避免误删多个同值任务
redis-cli LREM queue:processing 1 job-1001

业务动作可能重试，所以“至少一次”队列必须配合幂等键，例如把 job-1001 作为业务流水号。不要把 LREM 提前到业务调用之前，那会把 worker 崩溃窗口变成任务丢失窗口。

真正失败时如何回滚或转死信

当 worker 明确拿到 job-1001，但业务失败或主动放弃时，才把它重新放回 ready。若 ready 采用 LPUSH/RPOP 的 FIFO 约定，回滚可用 RPUSH 把任务放回右侧：

# 业务失败后再入队；实际生产环境还应递增重试次数
redis-cli RPUSH queue:ready job-1001
# 重新入队成功后，从处理中列表删掉旧记录
redis-cli LREM queue:processing 1 job-1001

更严格的实现会把 payload 放在 Hash，把 processing 列表只存唯一 ID，并记录领取时间、重试次数和最后错误。巡检程序发现 processing 中长时间未确认的 ID 后，可以先做幂等查询，再选择 RPUSH 重试；超过上限则移入 queue:dead，避免无限循环。

需要注意，客户端在 BLMOVE 返回附近断线时，应用可能不知道服务端到底返回了什么。此时不能因为“我没收到回复”就直接补发；应依靠唯一任务 ID、业务幂等记录或改用 Redis Streams 的消费组确认与 pending 机制。

上线前的四项检查

• 超时空返回是否只记录“暂无任务”，没有额外 RPUSH。
• processing 是否能保存领取后未确认的唯一 ID。
• ack 是否发生在业务成功之后，重试是否具备幂等保护。
• Redis Cluster 下 source 和 destination 是否满足多 key 操作的部署约束；否则应调整键设计或选择 Streams。

常见问题

timeout 设置为 0 会不会自动回滚？

不会。0 只表示无限等待；BLMOVE 成功移动后也不会替你处理业务失败。

BLMOVE 超时后需要执行 LREM 吗？

不需要。超时没有返回任务，processing 中不存在由这次调用产生的记录。

为什么不直接使用 BRPOPLPUSH？

BLMOVE 是它的可配置替代，可以明确源端和目标端方向；旧命令迁移时要重新核对左右端语义。