结论：应采用bullmq（依赖redis）负责调度逻辑，mongodb仅作元数据与日志持久化，而非直接用mongodb实现队列。因mongodb缺乏原子出队、优先级、延迟、重试等核心队列能力，硬造易致重复执行、任务丢失、状态不一致及监控困难。
直接说结论：用 BullMQ + MongoDB 作为元数据存储层，而不是直接用 MongoDB 实现队列逻辑。 MongoDB 本身不提供原子性出队、优先级调度、延迟任务、失败重试等队列核心能力；硬造会踩大量并发和一致性坑。BullMQ 是当前 Node.js 生态最成熟的 Redis-based 队列库，但它的 Redis 依赖可被替换为 MongoDB —— 关键在于用 MongoDB 存储任务元数据（如状态、日志、重试次数），而用轻量级协调机制（如 findAndModify 或事务）模拟“出队”动作。
为什么不能直接用 MongoDB 的 collection 当队列？
MongoDB 没有原生的 FIFO 原子出队操作。常见错误是：
- 用
findOne({ status: 'pending' })查，再用updateOne({ _id }, { $set: { status: 'processing' } })改 —— 这中间存在竞态：两个 worker 同时查到同个任务，都去更新，导致重复执行 - 用
findAndModify（已废弃）或findOneAndUpdate做原子更新，但无法保证严格 FIFO，尤其在分片集群下顺序不可靠 - 手动维护一个
queue_position字段并靠$inc排序 —— 写放大严重，索引膨胀快，查询变慢
这些方案在 QPS > 50 时就容易出现任务丢失、重复、卡死，且难以监控和重放。
如何用 BullMQ + MongoDB 实现混合架构？
核心思路是：BullMQ 负责调度逻辑（含重试、延迟、限流、事件广播），MongoDB 负责持久化任务上下文与审计日志。两者解耦，各司其职。
- 启动 BullMQ 时，
connection仍指向 Redis（必需），但所有任务的data字段只存关键 ID（如{ docId: 'abc123', action: 'export' }），真实 payload 和执行日志写入 MongoDB 的tasks集合 - Worker 处理前，先通过
docId从 MongoDB 加载完整数据；处理完后，用bulkWrite更新状态 + 写入执行日志，再调用 BullMQ 的done()或failed() - 在 MongoDB 中为
tasks集合建立复合索引：{ status: 1, createdAt: 1, priority: -1 }，用于人工排查、重试界面或离线分析 - 若必须零 Redis，可用
mongodb-memory-server做本地测试，但生产环境不建议 —— MongoDB 的读写延迟和锁行为不适合高频队列协调
优雅停机时 MongoDB 任务状态怎么同步？
这是最容易被忽略的一环：Node.js 进程收到 SIGTERM 时，BullMQ 会等待 active 任务完成，但 MongoDB 中对应文档的状态可能仍是 'processing'。若此时进程崩溃，该任务将“卡住”。
- 在
process.on('SIGTERM')中，除了调用queue.close()，还要显式更新 MongoDB 中所有status: 'processing'且updatedAt 的任务为 <code>'stale' - 启动时加一个恢复脚本：扫描
status: 'stale'的任务，按业务规则决定是重试（status = 'pending'）、丢弃，还是告警人工介入 - 不要依赖 MongoDB 的 TTL 索引自动清理 —— TTL 删除是非事务性的，可能在更新状态前就被删掉，导致状态丢失
真正难的不是“怎么把任务塞进数据库”，而是“怎么让状态变更在分布式环境下始终可追溯、可回滚、可对齐”。MongoDB 适合做事实记录，不适合做调度引擎 —— 把它当硬盘用，别当 CPU 用。
