我为什么单一消费者的场景下，要用 Redis List 当消息队列？

List 做队列，到底有多简单？

Redis List 是一个双向链表，做队列只需要两个命令：

bash 复制代码

# 生产者入队
LPUSH auto_material_tasks '{"task_id": 206}'

# 消费者阻塞出队
BLPOP auto_material_tasks 30

没有 consumer group、没有 ACK、没有 pending、没有 offset。

消息格式就一条 JSON，里面只放一个 task_id，消费者拿到 ID 后去 MySQL 查完整数据。

Redis 不存业务状态，只做"通知"这一件事。

在单一消费者的场景下，List 的简单性就是它的优势。

为什么不用 Stream？

Redis Stream 是 Redis 5.0 推出的正经 MQ 数据结构，有 ACK、消费者组、pending 列表、消息回溯、断点续消费,那为什么不用？

因为这些功能，项目里已经用 MySQL 实现了。

来看项目实际的任务模型：

bash 复制代码

┌─────────────┐     LPUSH      ┌──────────────┐     ClaimPendingTask     ┌─────────┐
│  Producer   │ ───────────────→│  Redis List   │←── (KEDA 监控长度) ─────│  KEDA   │
└─────────────┘                 └──────┬───────┘                         └────┬────┘
                                      │ BLPOP                                  │
                                      ▼                                  扩缩容 │
┌─────────────┐                 ┌──────────────┐                               │
│  Consumer   │ ──── 查完整数据 →│    MySQL     │←──────────────────────────────┘
└─────────────┘                 └──────────────┘

ACK？MySQL 的 CAS 认领已经做了

每个 worker 拿到的不是一个消息，而是去 MySQL 执行 ClaimPendingTask，这条 SQL 用 UPDATE ... WHERE status = 0 做乐观锁认领任务。

谁 update 到的行数 > 0，谁就"拿了锁"，其他 worker 自动跳过。

这本身就是 ACK 机制：认领成功 = 确认消费，不需要 Redis 再来一套 XACK。

消费者组？KEDA ScaledJob 一任务一进程

Stream 的消费者组解决的是"同一队列多个消费者如何分配消息"的问题。

本项目的消费者模型是 KEDA 监测 Redis List 长度，动态创建 K8s Job。

每个 Job 是一个独立进程，跑完就销毁。

不存在"多进程争抢同一个队列"的场景,伸缩的单位是进程，不是线程。

消息丢了？RetryScanOnce 定时扫描兜底

List 最大的硬伤是 BLPOP 弹出即删，消费者崩了消息就没了。

在项目里有个定时任务 RetryScanOnce，每隔一段时间就去 MySQL 扫描超时未完成的任务，重新塞回队列。

消息可靠性的兜底在 MySQL，不在 Redis。

Redis 丢消息可以容忍，因为 MySQL 里的状态没丢。

消息回溯？有Mysql任务表

Stream 支持根据消息 ID 回溯历史消息。

在项目里，队列消息体就一个 {"task_id": 206}，没有任何需要回溯的业务数据。

真要排查，去 MySQL 查任务表，完整的状态变更历史全在那。

为什么不用 MySQL 当队列？

轮询开销大 ：200 个 worker 每秒 SELECT ... WHERE status = 0 LIMIT 1，这就是 200 QPS 的空查询，纯浪费。
锁竞争激烈 ：SELECT FOR UPDATE 或 UPDATE ... WHERE status = 0，并发一高 MySQL 锁竞争严重，吞吐量上不去。
KEDA 不认 MySQL 列表长度：KEDA 原生支持监控 Redis List 长度做扩缩容，MySQL 只能自己写 metrics 接口。
BLPOP 零浪费：阻塞等，有消息立刻唤醒，没消息就等着，零 CPU 消耗。MySQL 轮询做不到这一点。

List 当通知，DB 当状态机

职责	承担者	为什么
任务通知	Redis List	快、阻塞、零轮询
任务状态	MySQL	事务、持久化、复杂查询
可靠性兜底	MySQL + 定时扫描	状态机不丢，消息就能补
弹性伸缩	KEDA + Redis List	原生支持 List 长度监控

代价是什么？

消息格式自己校验 ：Redis 不关心你塞的字符串是不是合法 JSON，应用层 json.Unmarshal 失败了就丢掉，打一行 error log。
没有死信队列：消息处理失败没有自动重试和转存，得自己写逻辑。
没有消息回溯：想重跑某条历史消息？去 MySQL 手动改任务状态。
不能广播：一条消息只能被一个消费者拿走，想多个服务同时收到？在业务层再发一条。

我为什么单一消费者的场景下，要用 Redis List 当消息队列？