LMOVE
LMOVE source destination <LEFT | RIGHT> <LEFT | RIGHT>
- 自版本
- 6.2.0
- 时间复杂度
- O(1)
- ACL 类别
-
@write,@list,@slow,
原子性地返回并移除存储在 source 中的列表的第一个/最后一个元素（取决于 wherefrom 参数），并将元素推送到存储在 destination 中的列表的第一个/最后一个元素（取决于 whereto 参数）。
例如：考虑 source 存储列表 a,b,c，destination 存储列表 x,y,z。执行 LMOVE source destination RIGHT LEFT 会导致 source 存储 a,b，destination 存储 c,x,y,z。
如果 source 不存在，则返回 nil 并且不执行任何操作。如果 source 和 destination 相同，则该操作等效于从列表中移除第一个/最后一个元素并将其作为第一个/最后一个元素推送到列表中，因此可以将其视为列表旋转命令（或者如果 wherefrom 与 whereto 相同，则为无操作）。
此命令取代了现在已弃用的 RPOPLPUSH。执行 LMOVE RIGHT LEFT 等效于它。
示例
模式：可靠队列
Redis 通常用作消息服务器来实现后台作业或其他类型消息任务的处理。通常通过在生产者端将值推送到列表中来获得队列的简单形式，并在消费者端使用 RPOP（使用轮询）或 BRPOP（如果客户端更适合使用阻塞操作）来等待这些值。
但是，在这种情况下，获得的队列不是 *可靠的*，因为消息可能会丢失，例如，在出现网络问题或消费者在收到消息后崩溃，但尚未处理它时。
LMOVE（或 BLMOVE，用于阻塞变体）提供了一种避免此问题的方法：消费者获取消息，同时将其推送到 *处理* 列表中。它将使用 LREM 命令，以便在消息被处理后将其从 *处理* 列表中移除。
其他客户端可以监控 *处理* 列表中长时间存在的项目，如果需要，可以将这些超时项目重新推送到队列中。
模式：循环列表
使用相同的源和目标键，LMOVE 可以使用单个 LRANGE 操作在 O(N) 时间内访问 N 个元素列表中的所有元素，而无需将整个列表从服务器传输到客户端。
上述模式即使在以下情况下也能正常工作
- 有多个客户端正在旋转列表：它们会获取不同的元素，直到访问列表中的所有元素，然后重新开始。
- 即使其他客户端正在积极地将新项目推送到列表的末尾。
这使得实现一个系统变得非常简单，该系统中一组项目必须由 N 个工作器持续地以最快的速度进行处理。一个例子是监控系统，它必须以最小的延迟检查一组网站是否可达，使用多个并行工作器。
请注意，此工作器实现易于扩展和可靠，因为即使消息丢失，该项目仍然在队列中，并且将在下一次迭代中进行处理。