Redis BLMOVE 怎样阻塞式转移可靠队列元素

Redis BLMOVE 适合解决“任务不能在消费者取到后立刻丢失”的列表队列问题。它会等待源列表出现元素，同时把元素从源列表的一端原子地移到目标列表的一端；本文约定待处理队列是 jobs:ready，处理中队列是 jobs:processing。

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

最小可靠队列形态是：生产者写入 jobs:ready，消费者用 BLMOVE jobs:ready jobs:processing RIGHT LEFT 5 领取任务，业务成功后再用 LREM 从处理中列表删除它。BLMOVE 只负责原子转移，不负责确认业务完成。

一、先把 BLMOVE 的四个方向参数固定下来

BLMOVE 的完整语法是 BLMOVE source destination LEFT|RIGHT LEFT|RIGHT timeout。前两个方向分别决定从源列表哪一端取、向目标列表哪一端放。可靠队列通常让生产者用 LPUSH 从左侧写入，消费者从右侧取出，因此取出顺序是先进先出。

# 生产者把任务放入待处理列表，右端最老的任务先被消费
LPUSH jobs:ready job:1001
LPUSH jobs:ready job:1002

# 消费者从 ready 右端取出，并把任务放到 processing 左端
BLMOVE jobs:ready jobs:processing RIGHT LEFT 5
# 返回 job:1001；此时 job:1001 已经不在 ready，而在 processing

这一步的关键不是记住命令名，而是确认两个列表的职责。jobs:ready 表示还没有被某个消费者领取，jobs:processing 表示已经分配但尚未完成。两者使用不同 key，才能让故障恢复有落脚点。

二、用 timeout 区分阻塞等待与本轮没有任务

最后一个参数是等待秒数。写成 0 表示一直等待；写成正数则在等待期内没有任务时返回空值。生产环境一般更容易管理有限等待，因为消费者可以在超时后检查退出信号、刷新指标或重新建立连接。

# 最多等待 5 秒；没有任务时返回 nil，不要把 nil 当成失败任务
BLMOVE jobs:ready jobs:processing RIGHT LEFT 5

# 持续阻塞适合专用消费者，但要配合连接关闭和优雅退出
BLMOVE jobs:ready jobs:processing RIGHT LEFT 0

BLMOVE 返回的是被转移的元素，而不是包含 key 和状态的对象。客户端封装时要把“收到空返回”“收到任务字符串”“Redis 连接错误”分成三类处理：空返回通常只是本轮超时，连接错误才需要进入重连或告警路径。

三、不要把“转移成功”误当成“业务完成”

BLMOVE 原子地改变两个列表，但它不知道任务对应的数据库写入、HTTP 调用或文件处理是否成功。消费者拿到任务后，应该在完成业务动作且确认结果可接受之后，用 LREM 删除处理中列表里的同一项。

# 任务载荷使用稳定 ID，便于成功确认和故障恢复
LPUSH jobs:ready job:1003
BLMOVE jobs:ready jobs:processing RIGHT LEFT 5

# 下面的命令只应在业务处理成功后执行
LREM jobs:processing 1 job:1003
# 返回 1 表示删除了一项；返回 0 说明可能已被恢复程序处理或载荷不匹配

如果多个任务可能拥有相同的字符串载荷，单独使用 LREM 会产生歧义。因此应让每条任务带稳定且唯一的 ID，例如 job:1003|payload-hash，或把 ID 和业务数据编码成一个 JSON 字符串，并让恢复程序按 ID 建立租约记录。BLMOVE 本身并不会替你做去重。

四、用 processing 列表承接崩溃后的恢复

消费者在 BLMOVE 返回后崩溃时，任务仍留在 jobs:processing，这比直接 RPOP 丢掉任务更容易恢复。但列表元素本身没有领取时间、消费者 ID 和重试次数，所以看门程序通常需要另外保存任务租约，例如用哈希或有序集合记录 job_id、领取时间和尝试次数。

# 恢复程序发现 job:1003 的租约已经超时后，再放回待处理队列
LPUSH jobs:ready job:1003
# 只有确认旧租约归属当前恢复轮次后，才从 processing 删除，避免误删新领取记录
LREM jobs:processing 1 job:1003

恢复动作要有幂等边界：先用租约版本或消费者令牌确认这仍是旧任务，再回推并删除旧记录。否则旧消费者刚恢复、看门程序同时回收时，可能出现重复执行。这里的“可靠”是可恢复和可观测，不等于严格的 exactly-once。

五、用指标判断这个设计是否够用

不要只用“命令很快”判断可靠队列设计。可以在同一 Redis 实例、相同任务大小和相同消费者数下，分别记录空闲等待和持续有任务两种场景：

BLMOVE 的命令复杂度是 O(1)，但总体吞吐仍受任务大小、网络往返、业务处理和恢复扫描影响。若压测中 processing 持续增长，优先检查确认路径和租约回收，而不是盲目把阻塞超时改成更大的数字。

六、集群和边界条件

BLMOVE 同时访问 source 与 destination 两个 key。在 Redis Cluster 中，这两个 key 需要放在同一 hash slot；可以使用相同的 hash tag，例如 jobs:{email}:ready 与 jobs:{email}:processing。如果两个 key 分属不同 slot，多 key 操作会受到集群路由约束。

源列表不存在或为空时，有限 timeout 会返回空；源列表最后一个元素被移动后，Redis 会删除空的源列表。目标 key 如果不存在，会在转移时创建为列表。若 key 已经是字符串、哈希等其他类型，则客户端应记录 WRONGTYPE 并停止把该任务当成普通超时。

总结

用 BLMOVE 搭可靠队列时可以记住四句话：RIGHT LEFT 适合常见 FIFO 领取；有限 timeout 让消费者有机会处理退出和指标；processing 列表只是处理中登记，不是完成确认；租约、幂等和回收器决定故障后能否恢复。任务量较小时，这个结构简单有效；如果需要可见性超时、批量领取或复杂确认语义，应把这些额外能力单独评估。

常见问题

BLMOVE 和 BRPOPLPUSH 有什么关系？

BLMOVE 的 RIGHT LEFT 组合可以表达旧式 BRPOPLPUSH 的典型方向，并且方向参数更明确。新设计应优先使用 BLMOVE，迁移时仍要核对客户端版本。

BLMOVE 超时返回空值会丢任务吗？

不会。超时只表示这次等待期间没有从源列表成功转移元素；已经转移到 processing 的任务不会因为另一个消费者超时而自动消失。

为什么不直接用 RPOP？

RPOP 只从 ready 列表删除并返回元素，消费者随后崩溃时没有处理中登记。BLMOVE 把删除和转入 processing 合成一次 Redis 操作，为恢复流程保留了任务位置。