[TOC] #### 1. 前言 --- 面试官问你：Redis 能做消息队列吗 ？ 你要是脱口而出 “能”，那大概率要被追问到哑口无言 能，但有条件。这一讲把 List 的能力边界讲清楚 #### 2. 基本操作 --- List 就是一个有序的列表，能从两头操作 ```bash lpush queue task1 task2 task3 # 从左边塞进去 rpop queue # 从右边取出来 ``` 左边进、右边出，先进先出，这就是一个队列 ```bash lrange queue 0 -1 # 查看全部 llen queue # 长度 ``` #### 3. 阻塞模式 --- 普通模式下，队列空了 `rpop` 直接返回 `nil`，你得不断轮询，浪费 CPU 阻塞模式解决了这个问题： ```bash brpop queue 30 ``` 队列空了就等着，有数据立刻返回，最多等 30 秒，这就是简单消息队列的核心机制 ```bash # 测试方法：打开两个终端窗口 # 窗口1：queue 是一个空的 list brpop queue 30 # 窗口2：往 queue 中推入数据，此时窗口1就会立刻返回推出的数据 lpush queue html ``` #### 4. list 当队列的局限 --- 说完能用的部分，说说不够用的地方 第一，没有消费确认 + 消息 rpop 之后就没了，消费者处理到一半挂了，消息就丢了，RabbitMQ 有 ACK 机制，处理完才确认删除 第二，不支持多消费者 + 一条消息只能被一个人取走，你想让多个服务都收到同一条消息（发布订阅模式），List 做不到 第三，不能回溯 + 消费完就没了，想重新消费历史消息？没门。Kafka 能按 offset 随便往前翻 所以结论是：简单场景够用，复杂场景老实上 RabbitMQ 或 Kafka #### 5. 适合 list 的场景 --- 最新消息列表： ```bash lpush news:latest '{"id":1,"title":"Redis教程"}' # 推入最新数据 lrange news:latest 0 9 # 最新10条 ``` 操作日志： ```bash lpush log:user:1001 "2026-05-08 10:00 登录" lrange log:user:1001 0 4 # 最近5条 ``` 简单任务队列：后台异步处理，不需要复杂特性时 #### 6. 本文小结 --- 小总结： + LPUSH + RPOP = 队列，BRPOP = 阻塞消费 + 没有消费确认、没有多消费者、不能回溯 + 简单场景够用，复杂场景用专业消息队列 + 适合：最新消息列表、操作日志、简单任务