Redis 的 RPOPLPUSH 命令是一个较少被单独讨论但非常关键的列表原语。它可以在一条命令中完成两个动作：从源列表的右侧弹出元素，然后把这个元素推入目标列表的左侧。因为 Redis 的命令执行是单线程串行的，所以这两个动作之间不会插入任何其他客户端命令，这就是所谓的原子移动。对于需要保证任务不丢失的队列场景，RPOPLPUSH 提供了一种比先 LPOP 再 RPUSH 更加可靠的替代方案。
RPOPLPUSH 的语义与原子性
RPOPLPUSH 命令的基本语法为 RPOPLPUSH source destination。source 是源列表，destination 是目标列表。该命令返回被移动的元素值；如果 source 不存在或者为空，则返回 nil。source 和 destination 可以是同一个列表，此时命令会把列表最右侧的元素旋转到最左侧，这在实现循环队列时非常有用。
原子性来源于 Redis 单线程执行命令的模型。Redis 在处理一条命令时不会被其他客户端的命令打断，因此从源列表弹出和向目标列表推入两个步骤天然是一个不可分割的整体。如果开发者自己组合使用 LPOP 和 RPUSH，在两条命令之间一旦客户端崩溃，元素就可能已经从源列表消失却没有进入目标列表，造成任务丢失。而 RPOPLPUSH 把这一步压缩成单条命令，从协议层就避免了中间状态。
时间复杂度方面，RPOPLPUSH 对列表两端操作，复杂度为 O(1)。这意味着即使队列中积压大量任务，该命令的执行耗时也不会随列表长度增长。不过需要注意，如果 destination 列表需要持久化，Redis 的 AOF 或者主从复制仍然会记录这条写操作，因此在极高吞吐场景下，命令本身的 O(1) 并不能完全代表系统开销。
# 将 task_queue 最右侧元素移动到 processing_queue 最左侧 RPOPLPUSH task_queue processing_queue # 查看源列表和目标列表 LRANGE task_queue 0 -1 LRANGE processing_queue 0 -1
用 RPOPLPUSH 构建可靠任务队列
常见的任务队列模式是：生产者使用 LPUSH 或 RPUSH 把任务写入待处理队列，消费者通过 RPOPLPUSH 把任务从待处理队列原子地转移到处理中队列。这样设计的好处是，即使消费者在处理任务过程中崩溃，任务仍然保存在处理中队列里，监控程序可以定期检查这些滞留任务，并把超时未完成的任务重新放回待处理队列。
下面是一个 Python 消费者的典型实现。它从 queue:pending 取出任务并移动到 queue:processing，处理成功后通过 LREM 从处理中队列删除该任务。如果处理失败，可以选择重新推回待处理队列，或者记录错误供人工介入。
import redis
import time
client = redis.Redis(host='127.0.0.1', port=6379, decode_responses=True)
def consume():
while True:
# 原子地取出任务并放入处理中队列
task = client.rpoplpush('queue:pending', 'queue:processing')
if task is None:
# 没有任务时短暂等待，避免空转
time.sleep(0.5)
continue
try:
# 处理具体任务
process(task)
# 处理成功后从处理中队列移除
client.lrem('queue:processing', 1, task)
except Exception as exc:
# 处理失败时记录日志，任务留在 processing 队列中等待恢复
log_error(task, exc)
这种模式的可靠性体现在两个层面。第一，任务在消费者领取的瞬间就进入了处理中队列，不会因为客户端崩溃而消失。第二，处理中队列本身就是任务的临时保管区，配合超时扫描逻辑就能实现重试。比如可以维护一个时间戳列表，或者把任务处理开始时间写入另一个有序集合，监控程序扫描超过 N 分钟仍未完成的任务，把它们重新放回待处理队列。
不过可靠队列并不等于零丢失。如果 Redis 服务器在任务进入处理中队列之后、消费者处理完成之前发生宕机，并且没有配置持久化或者主从切换，那么处理中队列里的任务仍然可能丢失。因此关键任务通常还需要结合 Redis 的 AOF 持久化、主从同步以及业务端的幂等处理。
阻塞版本 BRPOPLPUSH 与消费循环
当待处理队列为空时，普通 RPOPLPUSH 会立即返回 nil，消费者需要自行实现轮询等待。这种轮询方式会带来不必要的 CPU 占用和网络请求。Redis 提供了阻塞版本 BRPOPLPUSH source destination timeout，当 source 为空时客户端会阻塞，直到有元素可以移动或者超时时间到期。timeout 为 0 时表示无限阻塞。
使用 BRPOPLPUSH 后，消费者逻辑可以更简洁：阻塞等待任务，一旦拿到任务就处理，处理完继续等待。需要注意，BRPOPLPUSH 在阻塞期间不会占用 Redis 的执行线程，Redis 可以继续处理其他命令。客户端连接会处于等待状态，因此要合理设置客户端超时和连接池参数，避免连接被中间网络设备断开。
import redis
import time
client = redis.Redis(host='127.0.0.1', port=6379, decode_responses=True)
def blocking_consume():
while True:
# 阻塞等待新任务，timeout 为 0 表示无限阻塞
task = client.brpoplpush('queue:pending', 'queue:processing', timeout=0)
# 这里 task 不会为 None，除非连接被中断
try:
process(task)
client.lrem('queue:processing', 1, task)
except Exception as exc:
log_error(task, exc)
阻塞版本还有一个优势：当多个消费者同时调用 BRPOPLPUSH 等待同一个源列表时，Redis 会按照先到先服务的顺序唤醒其中一个客户端。这样天然实现了负载分发，不需要额外的分布式锁。但要小心 timeout 设置过短造成的无效唤醒，以及网络闪断导致的客户端重连风暴。
LMOVE 的替代关系与实战注意事项
从 Redis 6.2 开始，官方引入了 LMOVE source destination LEFT|RIGHT LEFT|RIGHT 命令，用来取代 RPOPLPUSH。LMOVE 可以自由指定弹出和推入的方向，不再局限于右弹出左推入。对应的阻塞版本是 BLMOVE。如果使用 Redis 6.2 及以上版本，建议优先使用 LMOVE 和 BLMOVE，因为它们在语义上更清晰，也支持更多队列模型。
# 语义等同于 RPOPLPUSH task_queue processing_queue LMOVE task_queue processing_queue RIGHT LEFT # 阻塞版本，超时 5000 毫秒 BLMOVE task_queue processing_queue RIGHT LEFT 5000
在实际生产环境中，有几个容易忽略的问题。第一，如果 destination 列表不断增长而消费者处理速度跟不上，内存可能被大量处理中任务占满。需要设置队列长度上限，或者对处理中队列做定期清理。第二，任务重试时要考虑幂等性，因为同一个任务可能被多个消费者重复处理。第三，当 source 和 destination 是同一个列表时，RPOPLPUSH 表现为列表旋转，这种技巧可以用来做简单的轮询调度，但如果列表很大，旋转后的顺序变化需要仔细验证。
总结来说，RPOPLPUSH 通过把弹出和推入合并为一条原子命令，为安全队列提供了可靠的基础原语。理解它的原子性边界、阻塞版本用法以及替代命令 LMOVE，有助于在 Redis 上实现健壮的消息队列，同时避免常见的任务丢失和重复消费问题。