一、List 是什么？
Redis List 的本质
有序的字符串序列，按插入顺序排列，两端操作快
你可以把它理解成：
双端队列
支持：
左边进 / 左边出
右边进 / 右边出
二、Redis 早期 List 的两种底层结构
Redis 的哲学：小数据用紧凑结构，大数据用通用结构
压缩列表
是什么？
一整块连续内存的紧凑结构
特点
内存占用极小
cache 友好
插入/删除需要移动内存
结构复杂（连锁更新问题）
双向链表
触发条件
元素数量多
或元素变大
node ⇄ node ⇄ node ⇄ node
特点
插入删除 O(1)
每个节点额外指针，内存浪费大
cache 命中率低
| 结构 | 问题 |
|---|---|
| ziplist | 修改代价大 |
| linkedlist | 内存碎片多 |
| 共存 | 代码复杂 |
三、Redis 3.2 之后的终极方案：QuickList
quicklist = 链表 + 压缩列表
quicklist 长什么样？
quicklist
┌────────┐ ┌────────┐ ┌────────┐
│ ziplist│ ⇄ │ ziplist│ ⇄ │ ziplist│
└────────┘ └────────┘ └────────┘
外层：双向链表
每个节点：一个 ziplist
quicklist 为什么比老方案好？
内存友好
一个 ziplist 里放多个元素
指针数量大幅减少
插入删除更快
一般只改某一个 ziplist
不用移动整个大 ziplist
cache 友好
ziplist 是连续内存
访问局部性强
操作复杂度
| 操作 | 时间复杂度 |
|---|---|
| LPUSH / RPUSH | O(1) |
| LPOP / RPOP | O(1) |
| LINDEX | O(n) |
| LRANGE | O(n) |
四、什么时候该用 List？
适合
消息队列（简单版）
时间线
任务队列
栈 / 队列
不适合
频繁随机访问
需要按 value 查找
五、消息队列到底要满足什么？
一个合格的消息队列（MQ），至少要满足这 3 点：
| 能力 | 含义 |
|---|---|
| 消息保序 | 消息按发送顺序被消费 |
| 去重能力 | 同一条消息不会被重复处理 |
| 消息可靠性 | 消息不会"丢" |
List 如何实现"消息保序"？（FIFO）
List 天然有序
Redis List 的特点：
有序
按插入顺序排列
两端操作快
所以它天然适合 FIFO 队列。
为什么是 LPUSH + RPOP？
生产者：LPUSH ←←←
List
消费者： →→→ RPOP
List 消费的第一个问题：CPU 空转
解决方案：BRPOP（阻塞式）
BRPOP 的行为
如果队列 为空
客户端阻塞（挂起）
一旦有新消息
立刻返回
不是忙等，是内核级等待
极大降低 CPU 消耗
非常适合 MQ 场景