LMOVE
LMOVE source destination <LEFT | RIGHT> <LEFT | RIGHT>
- 从以下位置开始可用：
- 6.2.0
- 时间复杂度：
- O（1）
- ACL 类别：
-
@write,@list,@slow,
原子方式返回并删除第一个/最后一个元素（head/tail 取决于
这wherefromargument）source，并将
元素（head/tail 取决于wheretoargument）destination.
例如：考虑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相同，则作等效于
从列表中删除 first/last 元素并将其推送为 first/last
元素，因此可以将其视为列表旋转命令（或
无作 ifwherefrom与whereto).
此命令取代了现已弃用的RPOPLPUSH.行为LMOVE RIGHT LEFT是等效的。
例子
模式：可靠队列
Redis 通常用作消息传递服务器来实现后台的处理
作业或其他类型的消息传递任务。
通常获得一种简单的队列形式，将值推送到
producer 端，并在 Consumer 端使用RPOP（使用轮询），或BRPOP如果客户端通过阻塞
操作。
但是，在此上下文中，获取的队列并不像消息那样可靠 丢失，例如在存在网络问题或消费者 在收到消息后立即崩溃，但仍待处理。
LMOVE（或BLMOVE）提供了一种避免
这个问题：Consumer 获取消息的同时推送消息
放入处理列表中。
它将使用LREM命令，以便在处理完消息后从 Processing 列表中删除消息。
其他客户端可以监视处理列表中剩余的项目 there too time 的 SET ，并且会将那些超时的项目推送到队列中 如果需要，请再次访问。
模式：循环列表
用LMOVE使用相同的源键和目标键，客户端可以访问
N 个元素列表的所有元素，一个接一个，以 O（N） 为单位，没有
使用单个LRANGE操作。
上述模式甚至在以下情况下有效：
- 有多个客户端轮换列表：它们将获取不同的 元素，直到访问完列表的所有元素，然后进程 重新 启动。
- 即使其他客户端正在积极推送列表末尾的新项目。
以上使得实现一个系统变得非常简单，其中一组项目必须 由 N 个 worker 尽可能快地连续处理。 例如，一个监控系统必须检查一组 Web 站点是否 可访问的，使用多个并行 worker，以尽可能短的延迟。
请注意，这种 worker 的实现很容易扩展且可靠。 因为即使消息丢失，该项目仍位于队列中，并且将 在下一次迭代中处理。