RPOPLPUSH (已弃用)

RPOPLPUSH source destination

自版本起

1.2.0

时间复杂度

O(1)

ACL 类别

@write, @list, @slow,

原子性地返回并删除存储在 source 中的列表的最后一个元素（尾部），并将该元素推送到存储在 destination 中的列表的第一个元素（头部）。

例如：假设 source 保存列表 a,b,c， destination 保存列表 x,y,z。执行 RPOPLPUSH 会导致 source 保存 a,b 而 destination 保存 c,x,y,z。

如果 source 不存在，则返回 nil 值，并且不执行任何操作。如果 source 和 destination 相同，则该操作等同于从列表中删除最后一个元素并将该元素作为列表的第一个元素推入，因此可以将其视为列表旋转命令。

示例

模式：可靠队列

Redis 通常用作消息服务器来实现后台作业或其他类型的消息任务的处理。一种简单的队列形式通常是在生产者端将值推入列表，并在消费者端使用 RPOP （使用轮询）或 BRPOP （如果客户端更好地使用阻塞操作）来等待这些值。

但是，在这种情况下，获得的队列不是可靠的，因为消息可能会丢失，例如，如果存在网络问题，或者消费者在收到消息但未对其进行处理之前崩溃。

RPOPLPUSH （或 BRPOPLPUSH 用于阻塞变体）提供了一种避免此问题的方法：消费者获取消息并将其推入处理列表。它将使用 LREM 命令，以便在消息处理完毕后将其从处理列表中删除。

另一个客户端可以监视处理列表中停留时间过长的项目，如果需要，可以将超时项目重新推入队列。

模式：循环列表

对同一个 source 和 destination 键使用 RPOPLPUSH ，客户端可以使用单个 LRANGE 操作，以 O(N) 的时间复杂度访问 N 个元素列表中的所有元素，而无需将整个列表从服务器传输到客户端。

即使出现以下情况之一或两者，上述模式仍然有效

• 有多个客户端在旋转列表：它们将获取不同的元素，直到访问列表中的所有元素，然后重新开始该过程。
• 其他客户端正在积极地在列表末尾推入新项目。

上述操作使得实现一个系统变得非常简单，在该系统中，一组项目必须尽可能快地由 N 个工作程序连续处理。例如，一个监控系统必须检查一组网站是否可以访问，并使用多个并行工作程序尽可能减少延迟。

请注意，这种工作程序实现是可扩展的，而且可靠，因为即使消息丢失，该项目仍然在队列中，并且将在下次迭代时被处理。

RESP2 响应

以下之一

• 批量字符串响应：被弹出并推入的元素。
• 空响应：如果源列表为空。

RESP3 响应

以下之一

• 批量字符串响应：被弹出并推入的元素。
• 空响应：如果源列表为空。