一、List 是什么？

Redis List 的本质

有序的字符串序列，按插入顺序排列，两端操作快

你可以把它理解成：

双端队列

支持：

左边进 / 左边出

右边进 / 右边出

二、Redis 早期 List 的两种底层结构

Redis 的哲学：小数据用紧凑结构，大数据用通用结构

压缩列表

是什么？

一整块连续内存的紧凑结构

特点

内存占用极小
cache 友好
插入/删除需要移动内存
结构复杂（连锁更新问题）

双向链表

触发条件

元素数量多

或元素变大

node ⇄ node ⇄ node ⇄ node

特点

插入删除 O(1)
每个节点额外指针，内存浪费大
cache 命中率低

三、Redis 3.2 之后的终极方案：QuickList

quicklist = 链表 + 压缩列表

quicklist 长什么样？

quicklist
┌────────┐ ┌────────┐ ┌────────┐
│ ziplist│ ⇄ │ ziplist│ ⇄ │ ziplist│
└────────┘ └────────┘ └────────┘

外层：双向链表

每个节点：一个 ziplist

quicklist 为什么比老方案好？

内存友好

一个 ziplist 里放多个元素

指针数量大幅减少

插入删除更快

一般只改某一个 ziplist

不用移动整个大 ziplist

cache 友好

ziplist 是连续内存

访问局部性强

操作复杂度

四、什么时候该用 List？

适合

消息队列（简单版）

时间线

任务队列

栈 / 队列

不适合

频繁随机访问

需要按 value 查找

五、消息队列到底要满足什么？

一个合格的消息队列（MQ），至少要满足这 3 点：

List 如何实现“消息保序”？（FIFO）

List 天然有序

Redis List 的特点：

有序

按插入顺序排列

两端操作快

所以它天然适合 FIFO 队列。

为什么是 LPUSH + RPOP？

生产者：LPUSH ←←←
List
消费者： →→→ RPOP

List 消费的第一个问题：CPU 空转

解决方案：BRPOP（阻塞式）

BRPOP 的行为

如果队列为空

客户端阻塞（挂起）

一旦有新消息

立刻返回

不是忙等，是内核级等待

极大降低 CPU 消耗
非常适合 MQ 场景