Redis List 队列怎么把待办任务移入处理中列表

Redis List 队列不要先执行一次 RPOP，再单独把任务写入“处理中”列表。两次命令之间如果消费者进程崩溃，任务已经离开待办队列，却没有留下可恢复记录。更稳妥的做法是使用 Redis 6.2.0 引入的 LMOVE：一次命令从 pending 取出任务并放入 processing，成功处理后再用 LREM 删除确认。

Redis List 队列应该怎样分层

先把状态拆成两个键：queue:pending 保存尚未领取的任务，queue:processing 保存已经交给消费者、但还没有确认完成的任务。生产者可以把任务追加到 pending 尾部；消费者从 pending 尾部取出，再把它放到 processing 头部，这样处理顺序清楚，处理中列表也能承担恢复依据。

如果直接用 RPOP，拿到任务后还要再执行 LPUSH processing。网络断开或进程退出时，两步无法作为一个整体完成，这正是普通 List 轮询容易丢任务的地方。

用 LMOVE 把任务原子转入处理中

四个方向参数分别决定从源列表哪一端弹出、向目标列表哪一端压入。对于“生产者从左到右追加、消费者按先进先出取出”的约定，可以这样执行：

# 准备两个待办任务，右端是队尾
redis-cli RPUSH queue:pending job-101 job-102

# 从 pending 尾部取出，放到 processing 头部
redis-cli LMOVE queue:pending queue:processing RIGHT LEFT

# 查看两个列表的当前状态
redis-cli LRANGE queue:pending 0 -1
redis-cli LRANGE queue:processing 0 -1

第一次转移返回 job-102。pending 留下 job-101，processing 的头部变成 job-102。官方命令参考说明，这个操作复杂度为 O(1)，源列表不存在时返回 nil 且不执行转移。

方向不要凭感觉填写：RIGHT LEFT 等价于旧的 RPOPLPUSH，但 Redis 6.2.0 起 RPOPLPUSH 已标记为弃用。新代码直接使用 LMOVE，既能表达来源和目标方向，也方便日后调整队列策略。

成功确认与超时重回队列

消费者拿到返回值后执行业务操作。只有业务真正成功，才从 processing 删除对应任务：

# 任务处理成功后，按完整值删除一次确认记录
redis-cli LREM queue:processing 1 job-102

# 任务超时或消费者恢复时，从处理中移回待办
redis-cli LMOVE queue:processing queue:pending RIGHT LEFT

LREM 的数量参数建议使用 1，避免同值任务较多时误删多条。生产环境还应给任务内容附带唯一 jobId 和领取时间；巡检程序只把超过处理时限的记录重新放回 pending。这样能把“已领取”和“已完成”分开，代价是重试时必须让业务具备幂等性。

空队列等待时改用 BLMOVE

如果消费者不想循环执行 LLEN、RPOP 轮询，可以使用 BLMOVE 的阻塞变体，让 Redis 在没有任务时等待。它仍然需要源键、目标键和两个方向参数，并额外接受超时时间。无论使用哪一种，都要先确认服务端版本至少是 6.2.0。

还要注意，LMOVE 同时访问源键和目标键；Redis 官方文档提示 clustered Redis 下多键操作存在额外行为约束。集群部署时，应先按实例的键槽规则确认两个键能否一起操作，不要把单机测试结果直接当成线上结论。

常见问题

LMOVE 找不到 pending 任务会怎样？

返回 nil，不会修改目标列表。消费者应把 nil 当作暂时没有任务，而不是当成业务失败。

为什么 processing 里还要保留任务？

它记录“已领取但未确认”的状态，消费者崩溃后可以按超时规则恢复；处理成功后才用 LREM 清掉。

LMOVE 能否把同一个 List 自己转给自己？

可以，但这会变成列表旋转，不是待办到处理中场景。两个不同键更容易表达可靠队列的状态边界。