bunqueue：不给 Redis 交运维费的 Bun 原生任务队列
阅读时间: 大约 8 分钟
bunqueue：不给 Redis 交运维费的 Bun 原生任务队列
Node/TS 生态的任务队列长期被 BullMQ/Bull 统治，而它们几乎都依赖 Redis——意味着你为了跑几个定时邮件，就得单独运维一个 Redis 实例。bunqueue 是 egeominotti 专门为 Bun 写的任务队列：默认内存或单文件 SQLite，零 Redis，号称 API 兼容 BullMQ，规模真的上来了再切 PostgreSQL 多 broker。本文基于其 GitHub README 做分析。
一、它解决什么问题
任务队列是「小而重」的基础设施：你需要延迟任务、定时任务（cron）、死信队列（DLQ）、重试，但为了这些功能常驻一个 Redis，对小团队是纯负担。bunqueue 的回答是：Bun 自带了 SQLite、HTTP、WebSocket、S3，那就一个外部依赖都不加——README 明确说运行时唯一依赖是 msgpackr，其余全用 Bun 内置。
两种形态：
- 嵌入式（embedded）：队列 + worker 在同一个进程里，一个对象搞定，数据落到一个
.db文件； - 独立服务器：
bunx bunqueue start起 TCP（:6789）+ HTTP（:6790），非 Bun 环境也能连；也有官方 Docker 镜像。
二、存储三段式：内存 → SQLite → PostgreSQL
bunqueue 的存储策略是「按规模升级」，这也是它最值得理解的设计：
| 阶段 | 后端 | 适用 |
|---|---|---|
| 零配置默认 | 内存 | 重启即丢，适合测试/短暂任务 |
| 零基础设施持久化 | 单文件 SQLite | 单机生产，免运维 |
| 多 broker 扩展 | PostgreSQL 15–18（推荐 18.6） | 多进程/多副本并发消费 |
README 明确：PostgreSQL 模式只在 server 端可用，嵌入式仍走内存/SQLite；MySQL 不支持。CI 验证了 PostgreSQL 15/16/17 与推荐的 18.6。Docker 部署上，从 2.9.5 起镜像同时发布到 Docker Hub 与 GHCR，分 Alpine / Debian / Debian slim / Distroless 四个基础镜像，支持 amd64 与 arm64。
三、性能口径：28 万 ops/秒怎么读
Koala 条目给出「单机标称 28 万操作每秒」。需要标注的是：这是官方称/Koala 转述的数字——README 正文没有在首页展开这一基准，性能数字指向单独的 Benchmarks 文档页，而该页路径我未能在当前 README 树中直接定位。更重要的是要理解这个数字的含义边界：
- 它大概率是内存模式下的入队/出队操作吞吐，不是 SQLite 持久化模式、更不是 PostgreSQL 多 broker 模式；
- 持久化到 SQLite 后，写吞吐会受 fsync 策略与单库锁制约；
- 多 broker 切到 PostgreSQL 后，瓶颈转移到 Postgres 连接与行锁。
换句话说，「28 万 ops/秒」是这个队列在最乐观配置下的峰值，不能直接外推到你开启持久化、跑真实 IO 任务后的生产表现。
四、官方自己承认的硬边界
SQLite 单节点是硬伤。Koala 点评准确：官方坦承不适合多区域分布式场景——SQLite 文件不能被多台机器同时读写。这也是为什么多 broker 必须切 PostgreSQL。
嵌入式与 server 模式能力不对等：PostgreSQL 多 broker 只在 server 端可用；你不能在嵌入式进程里靠 SQLite 横向扩。
MySQL 被明确排除。用 MySQL 当主库的团队无法直接复用同一套 broker 拓扑。
项目很年轻：issues 1、PR 1，最近提交「3 周前」，但版本已到 2.9.5——说明它在快速迭代，API 可能变动；「API 兼容 BullMQ」是迁移友好的承诺，但 BullMQ 的全部边角（rate limit、repeatable job 的所有语义、metrics）未必 1:1 对齐，迁移前要对自己用到的特性做验证。
DLQ/cron/S3 备份/MCP 是卖点，但成熟度未知：README 提到 SQLite S3 备份与 native MCP，这些是较新的能力，社区案例几乎为零。
五、适用与不适用场景
适合： 已经在用 Bun、不想为队列单独跑 Redis 的小团队/个人项目；单机部署、任务量中等、要求持久化但不需要分布式的场景；AI Agent 的后台任务/自动化流水线（README 明说 Built for AI agents and automation）；想从 BullMQ 迁移、又想顺手去掉 Redis 依赖的项目。
不适合： 需要多机横向扩展消费、多区域部署的生产队列（必须上 Postgres，且要自己评估 Postgres 当队列后端的压力）；重度依赖 BullMQ 全部高级特性且需要零风险迁移的团队；用 MySQL 当主库的栈。
六、客观分析：优势与意义
优势： 真·零外部依赖（仅 msgpackr），把「为队列运维 Redis」这件事直接删掉；嵌入式 API 极简；存储三段式给了清晰的升级路径；Docker 多镜像变体 + MCP 支持，对 AI 工作流友好。
局限： SQLite 单机天花板；PostgreSQL 多 broker 才是「扩展答案」，但那又把运维负担请了回来；性能数字缺可复核的公开基准；项目年轻、API 仍在变。
bunqueue 代表的是 Bun 生态「用内置能力替代外部中间件」的趋势：当 Bun 把 SQLite、WebSocket、S3 都做进运行时，很多原本要 Redis/Postgres 才能干的事，单机一个文件就够了。它的价值主张很务实——先用 SQLite 把队列跑起来，等真的需要分布式时再付 Postgres 的成本，而不是一上来就为可能永远用不到的扩展性买单。