Redis 数据类型 List 列表
列表类型是⽤来存储多个有序的字符串,如下图所⽰,a、b、c、d、e 五个元素从左到右组成了⼀个有序的列表,列表中的每个字符串称为元素(element),⼀个列表最多可以存储 2^32 - 1个元素。在 Redis 中,可以对列表两端插⼊(push)和弹出(pop),还可以获取指定范围的元素列表、获取指定索引下标的元素等。列表是⼀种⽐较灵活的数据结构,它可以充当栈和队列的⻆⾊,在实际开发上有很多应⽤场景。
![](https://i-blog.csdnimg.cn/direct/e616f21f529f4f82a1f94eae101edba8.png)
List 数据类型的特点
-
有序集合:List 是一个有序的字符串集合,元素的顺序由插入顺序决定。
-
支持多种操作:可以对 List 进行头部插入、尾部插入、头部弹出、尾部弹出等操作。
-
阻塞操作:支持阻塞式弹出操作,当 List 为空时,客户端可以等待直到有新元素被插入。
-
内存优化:Redis 会根据 List 的大小和内容自动选择合适的内部编码方式,以优化内存使用。
内部编码
Redis 的 List 数据类型有两种内部编码方式:
-
压缩列表(ziplist):当 List 中的元素数量较少(默认小于 512 个),且每个元素的大小较小(默认小于 64 字节)时,Redis 使用压缩列表来存储 List。
-
链表(linkedlist):当 List 的大小超过上述阈值时,Redis 会自动切换到链表编码。
-
快速列表(quicklist):自 Redis 3.2 起引入,结合了链表和压缩列表的优点,适用于大量数据存储和快速访问。
命令
LPUSH
将⼀个或者多个元素从左侧放⼊(头插)到 list 中。
语法:
LPUSH key element [element ...]
时间复杂度:只插⼊⼀个元素为 O(1), 插⼊多个元素为 O(N), N 为插⼊元素个数.
返回值:插⼊后 list 的⻓度。
⽰例:
![](https://i-blog.csdnimg.cn/direct/7f1e618cb90b4376ab08e10bcbc9c3db.png)
LPUSHX
在 key 存在时,将⼀个或者多个元素从左侧放⼊(头插)到 list 中。不存在,直接返回
语法:
LPUSHX key element [element ...]
时间复杂度:只插⼊⼀个元素为 O(1), 插⼊多个元素为 O(N), N 为插⼊元素个数.
返回值:插⼊后 list 的⻓度。
RPUSH
将⼀个或者多个元素从右侧放⼊(尾插)到 list 中。
语法:
RPUSH key element [element ...]
时间复杂度:只插⼊⼀个元素为 O(1), 插⼊多个元素为 O(N), N 为插⼊元素个数.
返回值:插⼊后 list 的⻓度。
⽰例:
![](https://i-blog.csdnimg.cn/direct/26748467d3b54609acbfe14fff0ceff3.png)
RPUSHX
在 key 存在时,将⼀个或者多个元素从右侧放⼊(尾插)到 list 中。
语法:
RPUSHX key element [element ...]
时间复杂度:只插⼊⼀个元素为 O(1), 插⼊多个元素为 O(N), N 为插⼊元素个数.
返回值:插⼊后 list 的⻓度。
LRANGE
获取从 start 到 end 区间的所有元素,左闭右闭。
语法:
LRANGE key start stop
时间复杂度:O(N)
返回值:指定区间的元素。
⽰例:
![](https://i-blog.csdnimg.cn/direct/79f8cd36994e482991cca67820948bd8.png)
LPOP
从 list 左侧取出元素(即头删)。
语法:
LPOP key
时间复杂度:O(1)
返回值:取出的元素或者 nil。
⽰例:
![](https://i-blog.csdnimg.cn/direct/b71cc14f16e94f2c83255ec04f3a6894.png)
RPOP
从 list 右侧取出元素(即尾删)。
语法:
RPOP key
时间复杂度:O(1)
返回值:取出的元素或者 nil。
⽰例:
LTRIM
将 key 只保留下标从 start 到 stop 的值。
语法:
LTRIM key start stop
时间复杂度:O(1)
⽰例:
LINDEX
获取从左数第 index 位置的元素。
语法:
LINDEX key index
时间复杂度:O(N)
返回值:取出的元素或者 nil。
⽰例:
![](https://i-blog.csdnimg.cn/direct/90fc9fa0257e43acb1a78dd7ce684a7f.png)
LINSERT
在特定位置插⼊元素。
语法:
LINSERT key <BEFORE | AFTER> pivot element
时间复杂度:O(N)
返回值:插⼊后的 list ⻓度。
⽰例:
![](https://i-blog.csdnimg.cn/direct/02545feee7a44ef4a34cfe6ae84e0313.png)
LSET
修改下标为 index 的元素。
语法:
LSET key index value
时间复杂度:O(1)
⽰例:
![](https://i-blog.csdnimg.cn/direct/fd2713d3d9434641b781b484fda01e78.png)
LLEN
获取 list ⻓度。
语法:
LLEN key
时间复杂度:O(1)
返回值:list 的⻓度。
阻塞版本命令
blpop 和 brpop 是 lpop 和 rpop 的阻塞版本,和对应⾮阻塞版本的作⽤基本⼀致,除了:
- 在列表中有元素的情况下,阻塞和⾮阻塞表现是⼀致的。但如果列表中没有元素,⾮阻塞版本会理解返回 nil,但阻塞版本会根据 timeout,阻塞⼀段时间,期间 Redis 可以执⾏其他命令,但要求执⾏该命令的客⼾端会表现为阻塞状态。
- 命令中如果设置多个键,那么会从左向右进⾏遍历键,⼀旦有⼀个键对应的列表中可以弹出元素,命令⽴即返回。
- 如果多个客⼾端同时多⼀个键执⾏ pop,则最先执⾏命令的客⼾端会得到弹出的元素。
以下演示为 blpop 和 brpop的区别:
- 列表不为空时:
![](https://i-blog.csdnimg.cn/direct/13260292e0194f9e9549e76df269aaf7.png)
lpop user:1:messages 得到 x 元素 ;blpop user:1:messages 得到 x 元素。两者⾏为⼀致。
- 列表不为空时,且 5 秒内没有新元素加⼊:
![](https://i-blog.csdnimg.cn/direct/94a3264429584120a260a90135bd55d8.png)
lpop user:1:messages ⽴即得到 nil ;blpop user:1:messages 5 执⾏命令 5 秒后得到 nil 。两者⾏为不⼀致。
- 列表不为空时,且 5 秒内有新元素加⼊:
lpop user:1:messages ⽴即得到 nil ;blpop user:1:messages 5 执⾏命令,直到新元素加⼊,得到新元素 。两者⾏为不⼀致。
BLPOP
LPOP 的阻塞版本。
语法:
BLPOP key [key ...] timeout
时间复杂度:O(1)
返回值:取出的元素或者 nil。
⽰例:
![](https://i-blog.csdnimg.cn/direct/7e7b69c9a3124752a65c521268366376.png)
BRPOP
RPOP 的阻塞版本。
语法:
BRPOP key [key ...] timeout
时间复杂度:O(1)
返回值:取出的元素或者 nil。
使用场景
消息队列
如图所⽰,Redis 可以使⽤ lpush + brpop 命令组合实现经典的阻塞式⽣产者-消费者模型队列,⽣产者客⼾端使⽤ lpush 从列表左侧插⼊元素,多个消费者客⼾端使⽤ brpop 命令阻塞式地从队列中
"争抢" 队⾸元素。通过多个客⼾端来保证消费的负载均衡和⾼可⽤性。
![](https://i-blog.csdnimg.cn/direct/819e81ac74214583a8bec4d2c48e2288.png)
微博 Timeline
每个⽤⼾都有属于⾃⼰的 Timeline(微博列表),现需要分⻚展⽰⽂章列表。此时可以考虑使⽤列表,因为列表不但是有序的,同时⽀持按照索引范围获取元素。
1)每篇微博使⽤哈希结构存储,例如微博中 3 个属性:title、timestamp、content:
hmset mblog:1 title xx timestamp 1476536196 content xxxxx
...
hmset mblog:n title xx timestamp 1476536196 content xxxxx
2)向⽤⼾ Timeline 添加微博,user:<uid>:mblogs 作为微博的键:
lpush user:1:mblogs mblog:1 mblog:3
...
lpush user:k:mblogs mblog:9
3)分⻚获取⽤⼾的 Timeline,例如获取⽤⼾ 1 的前 10 篇微博:
keylist = lrange user:1:mblogs 0 9
for key in keylist {
hgetall key
}
此⽅案在实际中可能存在两个问题:
- 1 + n 问题。即如果每次分⻚获取的微博个数较多,需要执⾏多次 hgetall 操作,此时可以考虑使⽤ pipeline(流⽔线)模式批量提交命令,或者微博不采⽤哈希类型,⽽是使⽤序列化的字符串类型,使⽤ mget 获取。
- 分裂获取⽂章时,lrange 在列表两端表现较好,获取列表中间的元素表现较差,此时可以考虑将列表做拆分。