介绍
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数据类型留待以后的文章在做介绍。
- 如何满足消息顺序保存的要求？
List本身按照先进先出的顺序访问和存储数据。所以，如果使用List作为消息队列来保存消息，就已经可以满足消息顺序保存的要求了。
List可以通过使用LPUSH + RPOP（反之亦然，RPUSH + LPOP）命令来实现消息队列。
- producer，生产者：使用命令LPUSH key value[value...]将消息插入到队列的头部。如果key不存在，则会创建一个空队列，然后插入消息。
- consumer，消费者：使用命令RPOP key按顺序读取队列的消息，先进先出。
但是，这里有一个问题。当生产者向List写入数据时，List不会主动通知消费者有新数据写入。如果消费者想要及时处理消息，则需要在程序中不断调用RPOP命令（例如使用while(1)循环）。如果有新数据写入，RPOP命令将返回结果；否则，RPOP 命令返回空值并继续循环。
所以，即使没有新的消息写入List，消费者仍然需要不断调用RPOP命令，这会导致消费者程序的CPU在执行RPOP命令中不断消耗，带来不必要的性能损失。
为了解决这个问题，Redis提供了BRPOP命令。 BRPOP命令也称为阻塞读。当客户端不读取队列数据时，会自动阻塞，直到有新数据写入队列，然后开始读取新数据。相比消费者程序自己不断调用RPOP命令，这种方式可以节省CPU开销。
- 如何处理重复消息？
消费者要实现重复消息的判断，需要满足两个需求：
- 每条消息都有一个全局ID。
- 消费者需要记录已经处理的消息的ID。消费者程序接收到消息后，可以将接收到的消息ID与已处理的消息的记录ID进行比较，以判断当前接收到的消息是否已经被处理。如果已经处理过了，那么消费者程序将不再处理它。
但List并不会为每条消息生成一个ID号，所以我们需要自己为每条消息生成一个全局唯一的ID 。生成后，当我们使用LPUSH命令将消息插入到List中时，消息中需要包含这个全局唯一的ID。
例如，执行以下命令，一条全局ID为10001、库存数量为9的消息被插入到消息队列中：
> LPUSH mq "10001:stock:9"
(integer) 1- 如何保证消息的可靠性？
消费者程序从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的文章中介绍。