我为什么单一消费者的场景下，要用 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 手动改任务状态。不能广播一条消息只能被一个消费者拿走想多个服务同时收到在业务层再发一条。

企业数字化 ERP 产品动态

相关推荐

AI工程师学习路径与大模型实战指南

1. AI工程师的职业前景与学习路径2023年被称为AI大模型元年，ChatGPT的爆发让全球看到了生成式AI的潜力。根据LinkedIn最新报告，AI工程师岗位需求年增长率达到74%，资深AI工程师年薪普遍在50-100万区间。这个领域最吸引人的特点是：即… · 2026/9/25 11:04:27

AI大模型技术栈与高效学习路径全解析

1. AI大模型行业现状与入门必要性2023年被称为AI大模型爆发元年，从ChatGPT到文心一言，各类大模型产品如雨后春笋般涌现。根据最新行业报告显示，全球AI大模型相关岗位需求同比增长超过300%，但合格人才供给量仅增长40%，存… · 2026/9/20 23:29:42

2026论文降重工具评测与最佳实践指南

1. 项目背景与需求分析 2026届毕业生即将面临论文写作与查重的严峻挑战。随着高校对学术不端行为的打击力度不断加大，论文重复率已成为决定学生能否顺利毕业的关键指标之一。根据近三年高校论文抽查数据显示，因重复率超标导致的论文不通过案例年均增长23… · 2026/7/29 14:31:47

I2C总线调试全攻略：从万用表到示波器，彻底解决ACK丢失问题

1. 从一根“不听话”的I2C总线说起调试嵌入式系统时，最让人头疼的场景之一，莫过于代码逻辑看起来天衣无缝，但传感器就是没反应。你翻遍数据手册，时序参数算了又算，上拉电阻也按推荐值焊了，可SDA和SCL两条线… · 2026/9/25 11:04:51

AI苹果育苗智能分选移栽机器人 QT信创完整工程

# AI苹果育苗智能分选移栽机器人 QT信创完整工程适配统信UOS、银河麒麟Qt5.12/5.15，针对苹果工厂化育苗开发；AI视觉识别**实生砧/八棱海棠/M9T337矮化砧、嫁接愈合度、苗木分级、花叶病/锈果病、缺苗弱苗**；依据国标苹果苗木壮苗标准自动分级筛选，机械臂柔性抓取移栽，土壤… · 2026/9/25 11:04:51

高速数字电路仿真设计与测试实战：从信号完整性到量产判断

最近几年，高速数字电路设计已经很少再有“画出来就能跑”的运气了。接口速率从几十Mbps涨到几十Gbps，信号边沿越来越陡，PCB上的一条走线、一个过孔、一段封装引脚，都可能变成影响系统能不能稳定跑起来的决定性因素。靠经验、靠余量… · 2026/9/25 11:04:51

NumPy傅里叶变换API从入门到实战：频谱分析与工程避坑指南

如果你做过信号处理、故障诊断或者图像分析，大概率绕不开 NumPy 的傅里叶变换接口——也就是numpy.fft那一组 API。我最开始在项目里用到它们，是因为需要从一段振动传感器数据里找出异常频率。当时我还不太明白原理，只知道调用np.fft.fft能得… · 2026/9/25 11:04:32

深圳售后完善的购物中心管理系统品牌企业实力参考

选购物中心管理系统必踩的4大常见坑很多购物中心、商管公司在选型数字化管理工具时，很容易掉进这些共性误区里： 怕选到功能适配差的系统：比如买了全链路方案却没法适配自身商圈的多业态布局，零售和餐饮商户不能共用一套系统&#… · 2026/9/25 11:04:26

力扣128最长连续序列：哈希表如何将复杂度优化到O(n)

在力扣刷题的过程里，128“最长连续数列”属于那种让人印象特别深的题目。它表面上看是一个数组遍历的问题，可实际上考察的是对时间复杂度的敏锐程度、对数据结构的选择，以及面对数字集合时能不能跳出“排序惯性”的思维定式。这道题被归类为中… · 2026/9/25 11:04:26

数值优化（Numerical Optimization）学习系列-03-共轭梯度方法（Conjugate Gradient）

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/9/25 1:00:31

创维E900V22D刷机全攻略：S905L3SB芯片兼容性解析与救砖实战

MQTT协议原理与Broker服务器搭建实战：从Mosquitto到EMQX

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

相关推荐

了解更多？预约专属演示