- 用法
-
RPOPLPUSH source destination
- 复杂度
- O(1)
- 始于
- 1.2.0
- ACL 类别
- @list, @write, @slow
- 有多个客户端轮换列表:它们将获取不同的元素,直到列表中的所有元素都被访问,然后该过程重新开始。
- 其他客户端正在主动将新项目推入列表末尾。
原子性地返回并移除存储在 source
列表的最后一个元素(尾部),然后将该元素推入存储在 destination
列表的第一个元素(头部)。
例如:假设 source
存储列表 a,b,c
,destination
存储列表 x,y,z
。执行 RPOPLPUSH
后,source
将存储 a,b
,destination
将存储 c,x,y,z
。
如果 source
不存在,则返回 nil
且不执行任何操作。如果 source
和 destination
相同,则此操作等同于从列表中移除最后一个元素并将其作为第一个元素推入列表,因此可以将其视为一个列表旋转命令。
示例
127.0.0.1:6379> RPUSH mylist "one"
(integer) 1
127.0.0.1:6379> RPUSH mylist "two"
(integer) 2
127.0.0.1:6379> RPUSH mylist "three"
(integer) 3
127.0.0.1:6379> RPOPLPUSH mylist myotherlist
"three"
127.0.0.1:6379> LRANGE mylist 0 -1
1) "one"
2) "two"
127.0.0.1:6379> LRANGE myotherlist 0 -1
1) "three"
模式:可靠队列
Valkey 常用作消息服务器,用于实现后台作业处理或其他类型的消息任务。一种简单的队列形式通常是通过在生产者端将值推入列表,然后消费者端使用 RPOP
(通过轮询)或 BRPOP
(如果阻塞操作更适合客户端)来等待这些值。
然而,在此上下文中,所获得的队列并不可靠,因为消息可能会丢失,例如在网络问题或消费者在接收到消息但尚未处理之前崩溃的情况下。
RPOPLPUSH
(或阻塞变体的 BRPOPLPUSH
)提供了一种避免此问题的方法:消费者获取消息的同时将其推入一个 *处理中* 列表。一旦消息处理完毕,它将使用 LREM
命令从 *处理中* 列表中移除该消息。
另一个客户端可以监视 *处理中* 列表中停留时间过长的项目,并在需要时将超时项目再次推回队列。
模式:循环列表
将 RPOPLPUSH
与相同的源和目标键一起使用,客户端可以以 O(N) 的复杂度逐个访问 N 个元素的列表中的所有元素,而无需通过单个 LRANGE
操作将整个列表从服务器传输到客户端。
即使发生以下一个或两个条件,上述模式也有效:
以上使得实现一个系统变得非常简单,在该系统中,N 个工作进程必须尽可能快地持续处理一组项目。一个例子是监控系统,它必须检查一组网站是否可访问,并使用多个并行工作进程以尽可能小的延迟进行检查。
请注意,这种工作进程的实现具有极佳的可扩展性和可靠性,因为即使消息丢失,项目仍然在队列中,并将在下一次迭代中得到处理。
RESP2 回复
以下之一
RESP3 回复
以下之一