RPOPLPUSH（已弃用）

RPOPLPUSH source destination

从以下位置开始可用：

1.2.0

时间复杂度：

O（1）

ACL 类别：

@write, @list, @slow,

原子方式返回并删除存储在source，并将元素推送到存储的列表的第一个元素 （head） 在destination.

例如：考虑source持有列表a,b,c和destination持有列表x,y,z. 执行RPOPLPUSH结果source占有a,b和destination占有c,x,y,z.

如果source不存在，则值nil返回，并且没有作 执行。 如果source和destination相同，则作等效于 从列表中删除最后一个元素，并将其作为 list 的 SET 命令，因此可以将其视为 list rotation 命令。

例子

模式：可靠队列

Redis 通常用作消息传递服务器来实现后台的处理 作业或其他类型的消息传递任务。 通常获得一种简单的队列形式，将值推送到 producer 端，并在 Consumer 端使用RPOP（使用轮询），或BRPOP如果客户端通过阻塞 操作。

但是，在此上下文中，获取的队列并不像消息那样可靠 丢失，例如在存在网络问题或消费者 在收到消息后但在处理消息之前崩溃。

RPOPLPUSH（或BRPOPLPUSH）提供了一种避免 这个问题：Consumer 获取消息的同时推送消息 放入处理列表中。 它将使用LREM命令，以便在处理完消息后从 Processing 列表中删除消息。

其他客户端可以监视处理列表中剩余的项目 在那里放置了太多时间，将超时的项目推送到队列中 如果需要，请再次访问。

模式：循环列表

用RPOPLPUSH使用相同的源键和目标键，客户端可以访问 N 个元素列表的所有元素，一个接一个，以 O（N） 为单位，没有 使用单个LRANGE操作。

即使出现以下一种或两种情况，上述模式也有效：

• 有多个客户端轮换列表：它们将获取不同的 元素，直到访问完列表的所有元素，然后进程 重新 启动。
• 其他客户端正在积极推送列表末尾的新项目。

以上使得实现一个系统变得非常简单，其中一组项目必须 由 N 个 worker 尽可能快地连续处理。 例如，一个监控系统必须检查一组 Web 站点是否 可访问的，使用多个并行 worker，以尽可能短的延迟。

请注意，这种 worker 的实现很容易扩展且可靠。 因为即使消息丢失，该项目仍位于队列中，并且将 在下一次迭代中处理。

RESP2 回复

以下选项之一：

• Bulk string reply：被弹出和推送的元素。
• nil 回复：如果源列表为空。

RESP3 回复

以下选项之一：

• Bulk string reply：被弹出和推送的元素。
• Null 回复：如果源列表为空。