Redis学习手册(List数据类型)
本文内容纲要：
一、概述：
在Redis中，List类型是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样，我们可以在其头部(left)和尾部(right)添加新的元素。在插入时，如果该键并不存在，Redis将为该键创建一个新的链表。与此相反，如果链表中所有的元素均被移除，那么该键也将会被从数据库中删除。List中可以包含的最大元素数量是4294967295。
从元素插入和删除的效率视角来看，如果我们是在链表的两头插入或删除元素，这将会是非常高效的操作，即使链表中已经存储了百万条记录，该操作也可以在常量时间内完成。然而需要说明的是，如果元素插入或删除操作是作用于链表中间，那将会是非常低效的。相信对于有良好数据结构基础的开发者而言，这一点并不难理解。
二、相关命令列表：
三、命令示例：
- LPUSH/LPUSHX/LRANGE:
/>redis-cli#在Shell提示符下启动redis客户端工具。
redis127.0.0.1:6379>delmykey
(integer)1
#mykey键并不存在，该命令会创建该键及与其关联的List，之后在将参数中的values从左到右依次插入。
redis127.0.0.1:6379>lpushmykeyabcd
(integer)4
#取从位置0开始到位置2结束的3个元素。
redis127.0.0.1:6379>lrangemykey02
- "d"
- "c"
- "b"
#取链表中的全部元素，其中0表示第一个元素，-1表示最后一个元素。
redis127.0.0.1:6379>lrangemykey0-1 - "d"
- "c"
- "b"
- "a"
#mykey2键此时并不存在，因此该命令将不会进行任何操作，其返回值为0。
redis127.0.0.1:6379>lpushxmykey2e
(integer)0
#可以看到mykey2没有关联任何ListValue。
redis127.0.0.1:6379>lrangemykey20-1
(emptylistorset)
#mykey键此时已经存在，所以该命令插入成功，并返回链表中当前元素的数量。
redis127.0.0.1:6379>lpushxmykeye
(integer)5
#获取该键的ListValue的头部元素。
redis127.0.0.1:6379>lrangemykey00 - "e"
LPOP/LLEN:
redis127.0.0.1:6379>lpushmykeyabcd
(integer)4
redis127.0.0.1:6379>lpopmykey
"d"
redis127.0.0.1:6379>lpopmykey
"c"
#在执行lpop命令两次后，链表头部的两个元素已经被弹出，此时链表中元素的数量是2
redis127.0.0.1:6379>llenmykey
(integer)2
LREM/LSET/LINDEX/LTRIM:
#为后面的示例准备测试数据。
redis127.0.0.1:6379>lpushmykeyabcdac
(integer)6
#从头部(left)向尾部(right)变量链表，删除2个值等于a的元素，返回值为实际删除的数量。
redis127.0.0.1:6379>lremmykey2a
(integer)2
#看出删除后链表中的全部元素。
redis127.0.0.1:6379>lrangemykey0-1
- "c"
- "d"
- "c"
- "b"
#获取索引值为1(头部的第二个元素)的元素值。
redis127.0.0.1:6379>lindexmykey1
"d"
#将索引值为1(头部的第二个元素)的元素值设置为新值e。
redis127.0.0.1:6379>lsetmykey1e
OK
#查看是否设置成功。
redis127.0.0.1:6379>lindexmykey1
"e"
#索引值6超过了链表中元素的数量，该命令返回nil。
redis127.0.0.1:6379>lindexmykey6
(nil)
#设置的索引值6超过了链表中元素的数量，设置失败，该命令返回错误信息。
redis127.0.0.1:6379>lsetmykey6hh
(error)ERRindexoutofrange
#仅保留索引值0到2之间的3个元素，注意第0个和第2个元素均被保留。
redis127.0.0.1:6379>ltrimmykey02
OK
#查看trim后的结果。
redis127.0.0.1:6379>lrangemykey0-1 - "c"
- "e"
- "c"
LINSERT:
#删除该键便于后面的测试。
redis127.0.0.1:6379>delmykey
(integer)1
#为后面的示例准备测试数据。
redis127.0.0.1:6379>lpushmykeyabcde
(integer)5
#在a的前面插入新元素a1。
redis127.0.0.1:6379>linsertmykeybeforeaa1
(integer)6
#查看是否插入成功，从结果看已经插入。注意lindex的index值是0-based。
redis127.0.0.1:6379>lindexmykey0
"e"
#在e的后面插入新元素e2，从返回结果看已经插入成功。
redis127.0.0.1:6379>linsertmykeyafteree2
(integer)7
#再次查看是否插入成功。
redis127.0.0.1:6379>lindexmykey1
"e2"
#在不存在的元素之前或之后插入新元素，该命令操作失败，并返回-1。
redis127.0.0.1:6379>linsertmykeyafterka
(integer)-1
#为不存在的Key插入新元素，该命令操作失败，返回0。
redis127.0.0.1:6379>linsertmykey1afteraa2
(integer)0
RPUSH/RPUSHX/RPOP/RPOPLPUSH:
#删除该键，以便于后面的测试。
redis127.0.0.1:6379>delmykey
(integer)1
#从链表的尾部插入参数中给出的values，插入顺序是从左到右依次插入。
redis127.0.0.1:6379>rpushmykeyabcd
(integer)4
#通过lrange的可以获悉rpush在插入多值时的插入顺序。
redis127.0.0.1:6379>lrangemykey0-1
- "a"
- "b"
- "c"
- "d"
#该键已经存在并且包含4个元素，rpushx命令将执行成功，并将元素e插入到链表的尾部。
redis127.0.0.1:6379>rpushxmykeye
(integer)5
#通过lindex命令可以看出之前的rpushx命令确实执行成功，因为索引值为4的元素已经是新元素了。
redis127.0.0.1:6379>lindexmykey4
"e"
#由于mykey2键并不存在，因此该命令不会插入数据，其返回值为0。
redis127.0.0.1:6379>rpushxmykey2e
(integer)0
#在执行rpoplpush命令前，先看一下mykey中链表的元素有哪些，注意他们的位置关系。
redis127.0.0.1:6379>lrangemykey0-1 - "a"
- "b"
- "c"
- "d"
- "e"
#将mykey的尾部元素e弹出，同时再插入到mykey2的头部(原子性的完成这两步操作)。
redis127.0.0.1:6379>rpoplpushmykeymykey2
"e"
#通过lrange命令查看mykey在弹出尾部元素后的结果。
redis127.0.0.1:6379>lrangemykey0-1 - "a"
- "b"
- "c"
- "d"
#通过lrange命令查看mykey2在插入元素后的结果。
redis127.0.0.1:6379>lrangemykey20-1 - "e"
#将source和destination设为同一键，将mykey中的尾部元素移到其头部。
redis127.0.0.1:6379>rpoplpushmykeymykey
"d"
#查看移动结果。
redis127.0.0.1:6379>lrangemykey0-1 - "d"
- "a"
- "b"
- "c"
四、链表结构的小技巧：
针对链表结构的Value，Redis在其官方文档中给出了一些实用技巧，如RPOPLPUSH命令，下面给出具体的解释。
Redis链表经常会被用于消息队列的服务，以完成多程序之间的消息交换。假设一个应用程序正在执行LPUSH操作向链表中添加新的元素，我们通常将这样的程序称之为"生产者(Producer)"，而另外一个应用程序正在执行RPOP操作从链表中取出元素，我们称这样的程序为"消费者(Consumer)"。如果此时，消费者程序在取出消息元素后立刻崩溃，由于该消息已经被取出且没有被正常处理，那么我们就可以认为该消息已经丢失，由此可能会导致业务数据丢失，或业务状态的不一致等现象的发生。然而通过使用RPOPLPUSH命令，消费者程序在从主消息队列中取出消息之后再将其插入到备份队列中，直到消费者程序完成正常的处理逻辑后再将该消息从备份队列中删除。同时我们还可以提供一个守护进程，当发现备份队列中的消息过期时，可以重新将其再放回到主消息队列中，以便其它的消费者程序继续处理。
本文内容总结：
原文链接：https://www.cnblogs.com/orangeform/archive/2012/03/16/2351859.html