千岛の摸鱼小栈

两个方向，四种组合#

List 是 Redis 里最容易让人”以为自己会了”的类型。打开文档一看：LPUSH、RPUSH、LPOP、RPOP，就四个命令嘛，左右推推。合上文档开始写代码，写到一半发现不太确定：“等等，LPUSH + RPOP 是队列还是栈来着？”

这个困惑的根源是——List 同时能做队列和栈，但方向选择不一样，容易搞混。

先把基础操作理清楚：

1
# 从左侧推入
2
LPUSH mylist "a" "b" "c"
3
# mylist: [c, b, a]    ← 注意顺序！最后推的 "c" 在最左边
4

5
# 从右侧推入
6
RPUSH mylist "x" "y"
7
# mylist: [c, b, a, x, y]
8

9
# 从左侧弹出
10
LPOP mylist   # → "c"（最左边的）
11

12
# 从右侧弹出
13
RPOP mylist   # → "y"（最右边的）

LPUSH 有个容易踩的小坑：它把最后一个参数放在最左。LPUSH mylist "a" "b" "c" 的结果是 [c, b, a]，不是 [a, b, c]。想要保持顺序，用 RPUSH mylist "a" "b" "c"。

四个命令排列组合，搞出两种经典模式：

也可以反着来——RPUSH + LPOP 同样是队列。社区习惯用 LPUSH + RPOP，因为直觉上”从左边推进去，从右边流出来”，好记。

这个模型不复杂，看图就清楚#

动画里上半部分是队列模式（LPUSH + RPOP）：蓝色元素从左进、从右出，先进来的先出去。下半部分是栈模式（LPUSH + LPOP）：绿色元素同侧进出，后进来的反而先出去。

看完这张图，以后再也不会搞混了。

阻塞弹出：List 最实用的功能#

List 最妙的设计不是双向，是 阻塞弹出 —— BLPOP 和 BRPOP。

普通的 RPOP 在队列为空时返回 nil（空）。你只能写成死循环：

1
while True:
2
    task = redis.rpop("queue")
3
    if task:
4
        process(task)
5
    else:
6
        time.sleep(0.1)   # 空转，又慢又浪费 CPU

两个问题：一是 0.1 秒的延迟（消息来了要等最多 100ms 才被处理），二是 Redis 被无效请求轰炸。

BRPOP 解决的就是这个：

1
# 队列为空就挂起，有数据了立即返回
2
task = redis.brpop("queue", timeout=5)
3
if task:
4
    process(task[1])

timeout=5 的意思是：如果 5 秒内没数据，返回 None。设为 0 就无限等。拿到数据后几乎零延迟。

一个细节值得注意： BRPOP 返回的是一个元组 (key, value)，不是直接返回值。因为 BRPOP 可以同时监听多个队列：

1
# 优先消费 high 队列，没数据才看 low 队列
2
BRPOP high_queue low_queue 5

这在业务上很实用——比如 VIP 用户的邮件优先发送、付费任务优先处理。Redis 按参数顺序检查，哪个队列先有数据就返回哪个。

当消息队列用：够用但要知道边界#

List + BRPOP 组合是一个轻量级消息队列。部署简单，不需要额外组件，适合很多场景。

生产者：

1
def produce(task_json):
2
    redis.lpush("task_queue", task_json)

消费者：

1
def consume():
2
    while True:
3
        try:
4
            result = redis.brpop("task_queue", timeout=5)
5
            if result is None:
6
                continue
7
            _, task_json = result
8
            process(task_json)
9
        except Exception as e:
10
            logger.error(f"处理失败: {e}")
11
            # 注意：消息已经丢了！

但这段代码藏了一个致命问题——BRPOP 拿到消息后立即从 List 删除了。如果 process(task_json) 抛了异常或者进程崩溃，这条消息就没了。

这就是 List 作为消息队列的核心局限：没有 ACK 机制。消息一旦弹出就没有回头路。

1
# 从 source 弹出，原子性地推入 backup
2
BLMOVE task_queue backup_queue RIGHT LEFT 5

List 内部怎么存的：Quicklist#

前面聊 Hash 的时候说了 listpack 省内存。List 也用 listpack，但组织方式不一样。

List 底层是 quicklist——一个双向链表，每个节点里放一个 listpack。

1
head → [listpack: a, b, c, d] ↔ [listpack: e, f, g] ↔ [listpack: h, i] ← tail

为什么不用一个巨大的 listpack？因为 List 经常在两端操作，如果全放在一个连续内存块里，头部插入要移动所有元素，O(n)。而 quicklist 中部插入只需要动一个节点。

为什么不用纯链表（每个节点一个元素）？每个链表节点有指针开销（prev/next），几十万个元素就是几十万对指针，内存浪费严重。quicklist 每个节点装多个元素，摊薄了指针成本。

中间不常用的节点还会被 LZF 压缩，首尾节点保持未压缩状态以保证两端操作的性能。

两个关键配置：

1
list-max-listpack-size -2    # 每个节点最大 8KB（-2 是默认）
2
list-compress-depth 0        # 0=不压缩，1=首尾各 1 个不压缩

一般不用改。但如果你用 List 做消息队列且消息量很大，把 list-compress-depth 设为 1 或 2 能省不少内存。

几个顺手的小技巧#

1
LPUSH recent_logs "log_entry_6"
2
LTRIM recent_logs 0 4    # 只保留最新的 5 条

1
LRANGE messages 0 19     # 第 1 页（20 条）
2
LRANGE messages 20 39    # 第 2 页

1
LMOVE pending processing RIGHT LEFT
2
# 从 pending 右边弹出，从 processing 左边推进去

1
LLEN mylist

总结#

List 最厉害的就两点：阻塞弹出 和 双向操作。

阻塞弹出让它从”数据结构”跨到了”基础设施”——一个极简的消息队列，不需要额外组件。但消息可靠性、消费者组这些进阶需求，List 满足不了，要向上用 Stream。

双向操作让它同时胜任队列和栈，加上 LMOVE、LTRIM 这些周边命令，在日常开发里出现的频率比想象中高得多。

下一篇聊 Set——无序不重复、交集并集差集。共同好友、标签系统、随机抽奖，都藏在 Set 里。

这是 Redis 学习系列的第 4 篇。下一篇：Redis学习系列 | 共同好友原来这么算