Redis的List类型

一.List类型

简单介绍

列表的List相当于数组或者顺序表。

列表两端插入和弹出操作：

列表的获取、删除操作：

二.List的常用命令

1.LPUSH

按照顺序进行依次进行头插元素

演示：

2.LRANGE

查看LIst中指定范围的元素

演示：

此处的序号和下标无关，这个序号是专门给结果集使用的序号。在hash操作也可能会得到这种带有序号的结果，这种序号仅仅是标识返回元素的顺序也和下标无关，hash类型无下标的概念。

注意：

在Redis当中，没有采取当下标越界时，就返回一个异常的策略，而是尽可能的获取给定区间的元素，如果给定区间非法，比如超出下标就会尽可能获取对应的内容：

当如果两个下标都越界了，此时就获取不到元素：

3.LPUSHX

LPUSHX和LPUSH不同的是，LPUSHX只能在key存在的链表上进行头插，而不能在不存在的Key上进行头插

演示：

4.RPUSH

和LPUSH用法相同，只不过是尾插

演示：

5.RPUSHX

和LPUSHX效果类似，只能在已存在的key上进行操作。

演示：

6.LPOP

头删

演示：

7.RPOP

尾删

演示：

需要注意的是此处的redis版本比较低，所以在RPOP命令中的count没办法使用，这个是后续版本出来的新功能，这里的redis版本较低不支持。

8.LINDEX

获取从左边第index位置的元素

演示：

9.LINSERT

在特定位置插入元素

演示：

注意：

LINSERT是找到一个基准值后，在它之前或者之后进行插入，如果此时有列表中有两个值都符合LINSERT中的基准值，此时会在列表中开始从左往右进行查找，最先查找到的就作为基准值。

10.LLEN

查询列表key的长度

演示：

11.LREM

LREM => List Remove 删除，count表示要删除的个数，element表示要删除的值

• count > 0，列表从左往右删除count个符合element的元素
• count < 0，列表从右往左删除 |count|个 符合element的元素
• count = 0，删除列表中全部符合element的元素

演示：

• count > 0：

• count < 0：
  

• count = 0：
  

12.LTRIM

删除指定下标范围外的所有元素

演示：

13.LSET

根据下标修改元素

演示：

注意：
lindex可以很好的处理下标越界的情况，直接返回nil，对于lset来说会直接报错。

三.阻塞命令

BRPOP和BLPOP阻塞版本的命令，对应的就是LPOP和RPOP这两个不是阻塞版本的命令。

如果list中存在元素，BLPOP和BRPOP 就和 LPOP and RPOP的功能相同。

如果list中不存在元素，BLPOP和BRPOP 就会产生阻塞，一直阻塞到list插入元素为止。

但是阻塞版本的命令会根据timeout阻塞一段时间，因为BLPOP和BRPOP可以设置阻塞时间，而且，期间redis可以执行其他命令。

此处的BLPOP和BRPOP看起来好像会因为阻塞的问题消耗很多时间，但是实际上并不会对redis服务器产生负面影响。

在使用BLPOP和BRPOP的命令中如果设置了多个key，那么会从左往右进行遍历key，一旦有一个key对应的列表中可以弹出元素，命令立即返回。

Redis新版的等待时间支持小数，旧版本不支持小数。

1.BRPOP

阻塞命令的尾删

演示：

（i）针对不是空的列表进行操作：

（ii）针对空列表进行操作：

（iii）针对空列表使用阻塞命令：

针对空列表使用阻塞命令时，使用另一个reids客户端进行插入数据则可以将执行BRPOP的客户端的阻塞给结束。

此时还没有在另一个reids客户端进行插入数据操作，此时第一个redis客户端使用了BRPOP则处于阻塞状态。

当第二个redis客户端将数据插入时，第一个redis客户端此时的阻塞就结束了。

（iv）针对多个key进行操作

2.BLPOP

阻塞命令的头删

演示：
和BRPOP用法相同就不再重复。

四.List的内部编码

现在List的内部编码不再是之前的老版本的ziplist和Linkedlist了，现在最新的版本是使用的quicklist，quicklist是基于ziplist和Linkedlist的结合体。

五.List的应用场景

1.List作为数组来存储多个元素

在MySQL中表示学生和班级信息是通过两张表进行的：

如果此时需要查询制定班级中有哪些同学，那么在redis中就可以通过图中的方式进行设计：

存储班级和学生的信息的那张表格中，是通过hash类型进行存储的，下面的表格则是通过列表来进行保存classId = 1时，有哪些学生是这个班级的。

此时这个形式是列表，列表类似于数组来存储学生的id，如果不使用第一个表格的hash类型来存储学生和班级的信息的话，也可以使用JSON的方式放在列表当中，就可以不需要在通过hash类型的表格来进行存储。

2.作为消息队列

只有一个消费者能够抢到元素，抢到元素是通过谁先执行brpop的顺序来排序的，所以谁先执行brpop命令，谁最先抢到元素。

假设现在消费者的顺序是1，2，3 生产者进行 lpush 时，消费者1就会最先抢到元素，此时消费者1拿到元素之后，如果还想继续抢元素，就必须重新执行brpop的命令。

当消费者1重新执行brpop后，此时的消费者顺序就变成了2，3，1了，此时生产者再来一个元素，消费者2就能够抢到元素，此时如果你消费者2又想抢到元素，也需要重新执行brpop命令。

此时的消费者的顺序就是3，2，1了，之后就是以此类推。

3.多频道消息队列

多个频道/列表的使用在日常中是非常常见的，比如说现在大家天天都在刷的短视频，就是基于这种消息队列进行实现的一些功能。

比如说，使用一个通道来进行传输短视频的数据，还可以使用一个通道来传输弹幕，还可以使用一个频道来传输点赞，转发，收藏的数据……

4.微博Timeline

1）每篇微博使用hash来进行存储，例如微博的3个属性：title、timestamp、content：

2）向用户Timeline添加微博，user::mblogs作为微博的键：

3）分页获取用户的Timeline，例如获取用户1的前10篇微博：

情况1：
在第三步进行分页获取用户的微博时，多次使用hgetall操作，可能会导致循环次数比较多，因为不确定一页中的数据是多少，所以就会触发很多次hgetall，就会有很多的网络请求。

此时可以通过pipeline流水线（管道）的方式来进行解决这种很多的网络请求，因为此时有很多个redis命令，所以可以通过pipeline来把这些redis命令合并成一个网络请求进行通信，大大降低了客户端和服务器之间的交互次数。

情况2：

分裂文章时，使用lrange在列表的两端表现会比较好，但是如果获取列表的中间元素就会表现比较差，此时可以考虑将列表进行划分。

假设某个用户发了1w个微博，此时list的长度就是1w，就可以把这个1w个微博进行拆成10份，每个就是1k个微博。

5.栈和队列的命令组合