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

我为什么单一消费者的场景下要用 Redis List 当消息队列List 做队列到底有多简单Redis List 是一个双向链表做队列只需要两个命令# 生产者入队LPUSH auto_material_tasks{task_id: 206}# 消费者阻塞出队BLPOP auto_material_tasks30没有 consumer group、没有 ACK、没有 pending、没有 offset。消息格式就一条 JSON里面只放一个task_id消费者拿到 ID 后去 MySQL 查完整数据。Redis 不存业务状态只做通知这一件事。在单一消费者的场景下List 的简单性就是它的优势。为什么不用 StreamRedis Stream 是 Redis 5.0 推出的正经 MQ 数据结构有 ACK、消费者组、pending 列表、消息回溯、断点续消费,那为什么不用因为这些功能项目里已经用MySQL实现了。来看项目实际的任务模型┌─────────────┐ LPUSH ┌──────────────┐ ClaimPendingTask ┌─────────┐ │ Producer │ ───────────────→│ Redis List │←──(KEDA 监控长度)─────│ KEDA │ └─────────────┘ └──────┬───────┘ └────┬────┘ │ BLPOP │ ▼ 扩缩容 │ ┌─────────────┐ ┌──────────────┐ │ │ Consumer │ ──── 查完整数据 →│ MySQL │←──────────────────────────────┘ └─────────────┘ └──────────────┘ACKMySQL 的 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 手动改任务状态。不能广播一条消息只能被一个消费者拿走想多个服务同时收到在业务层再发一条。