介绍

List 列表是一个简单的字符串列表，按插入顺序排序，元素可以从头部或尾部添加到 List 列表中。

列表的最大长度为 2^32 - 1，也就是说，每个列表支持超过 40 亿个元素。

内部实现

List类型的底层数据结构是通过双向链表或压缩列表实现的：

• 如果列表中元素的数量少于 512（默认值，可通过 list-max-ziplist-entries 配置），且列表中每个元素的值少于 64 字节（默认值，可通过 list-max-ziplist-value 配置），Redis 将使用压缩列表作为 List 类型的底层数据结构；
• 如果列表元素不符合上述条件，Redis 将使用双向链表作为 List 类型的底层数据结构；

不过，在 Redis 3.2 版本之后，List 数据类型的底层数据结构只由 quicklist 实现，取代了双向链表和压缩列表。

常用命令

以下是Redis List类型的一些常用命令：

• LPUSH key value [value...]：将一个或多个值插入列表的头部。
• RPUSH key value [value...]：将一个或多个值插入列表尾部。
• LPOP key：删除并返回列表头部的元素。
• RPOP key：删除并返回列表尾部的元素。
• LLEN key：获取列表的长度。
• LRANGE key start stop：获取列表指定范围内的元素。
• LREM key count value：按照指定数量移除列表中的元素。
• LSET key index value：设置列表中指定索引处的元素
• LTRIM key start stop：修剪列表。

使用例子：

> lpush mq 10001:stock:9
(integer) 1
> lpush list v1
(integer) 1
> rpush list v2
(integer) 2
> rpush list v3
(integer) 3
> llen list
(integer) 3
> lrange list 0 2
1) "v1"
2) "v2"
3) "v3"
> lpop list
"v1"
> llen list
(integer) 2

应用场景

1. 消息队列

消息队列在访问和存储消息时，必须满足三个要求，分别是可保持消息顺序、可处理重复消息和确保消息可靠性。

Redis的List和Stream这两种数据类型，可以满足消息队列的这三个要求。我们先了解一下基于List的消息队列的实现方法，介绍Stream数据类型留待以后的文章在做介绍。

1. 如何满足消息顺序保存的要求？

List本身按照先进先出的顺序访问和存储数据。所以，如果使用List作为消息队列来保存消息，就已经可以满足消息顺序保存的要求了。

List可以通过使用LPUSH + RPOP（反之亦然，RPUSH + LPOP）命令来实现消息队列。

1. producer，生产者：使用命令LPUSH key value[value...]将消息插入到队列的头部。如果key不存在，则会创建一个空队列，然后插入消息。
2. consumer，消费者：使用命令RPOP key按顺序读取队列的消息，先进先出。

但是，这里有一个问题。当生产者向List写入数据时，List不会主动通知消费者有新数据写入。如果消费者想要及时处理消息，则需要在程序中不断调用RPOP命令（例如使用while(1)循环）。如果有新数据写入，RPOP命令将返回结果；否则，RPOP 命令返回空值并继续循环。

所以，即使没有新的消息写入List，消费者仍然需要不断调用RPOP命令，这会导致消费者程序的CPU在执行RPOP命令中不断消耗，带来不必要的性能损失。

为了解决这个问题，Redis提供了BRPOP命令。 BRPOP命令也称为阻塞读。当客户端不读取队列数据时，会自动阻塞，直到有新数据写入队列，然后开始读取新数据。相比消费者程序自己不断调用RPOP命令，这种方式可以节省CPU开销。

2. 如何处理重复消息？

消费者要实现重复消息的判断，需要满足两个需求：

• 每条消息都有一个全局ID。
• 消费者需要记录已经处理的消息的ID。消费者程序接收到消息后，可以将接收到的消息ID与已处理的消息的记录ID进行比较，以判断当前接收到的消息是否已经被处理。如果已经处理过了，那么消费者程序将不再处理它。

但List并不会为每条消息生成一个ID号，所以我们需要自己为每条消息生成一个全局唯一的ID 。生成后，当我们使用LPUSH命令将消息插入到List中时，消息中需要包含这个全局唯一的ID。

例如，执行以下命令，一条全局ID为10001、库存数量为9的消息被插入到消息队列中：

> LPUSH mq "10001:stock:9"
(integer) 1

3. 如何保证消息的可靠性？

消费者程序从List中读取一条消息后，List将不再保留这条消息。所以，如果消费者程序在处理消息的过程中出现故障或者崩溃，就会导致消息没有完成。那么，消费者程序重启后，将无法再次从List中读取消息。

为了支持保留消息，List类型提供了BRPOPLPUSH命令。该命令的作用是让消费者程序从一个List中读取一条消息。同时Redis会将这条消息插入到另一个List（可以称为备份List）中进行保留。

这样，如果消费者程序读取了消息但未能正常处理，则重启后可以从备份List中读取该消息并重新处理。

好了，到这里就稍作总结一下，基于List类型的消息队列满足了消息队列的三大要求（消息顺序保存、处理重复消息、保证消息可靠性）。

• 消息顺序保存：使用LPUSH + RPOP（或RPUSH + LPOP）；
• 阻塞读：使用 BRPOP；
• 重复消息处理：生产者自行实现全局唯一ID；
• 消息可靠性：使用 BRPOPLPUSH。

List作为消息队列有什么缺陷？

List不支持多个消费者消费同一条消息，因为一旦某个消费者拉取了一条消息，这条消息就会从List中删除，不能再被其他消费者消费。

要实现一条信息可以被多个消费者消费，就需要将多个消费者组成一个消费者组，这样多个消费者就可以消费同一条信息，但 List 类型不支持消费者组的实现。

这就带来 Redis 从 5.0 版本开始提供的 Stream 数据类型。 Stream同样可以满足消息队列的三大需求，并且还支持“消费者组”形式的消息读取。我们会在后续关于Stream的文章中介绍。