MongoDB直播间弹幕存储模型设计：写入悬挂并发优化

许多开发者在搭建直播间弹幕系统时，都会遇到同一个典型痛点：弹幕写入卡在insertOne操作上，并发越高速度越慢，最终甚至抛出WriteConflict错误。实际上，这并非MongoDB本身性能低下，而是默认的单文档插入机制在高并发场景下直接触发了写锁瓶颈。每条弹幕单独执行insertOne，1000 QPS意味着每秒需完成1000次磁盘刷写和索引更新，当writeConcern: "majority"时，延迟自然急剧上升。真实压测中，你看到的那些错误日志，通常不是服务崩溃，而是写入队列在排队等待锁释放。

弹幕写入为什么总是卡在 insertOne 上？

解决问题的关键不在于增加机器，而在于将“写操作”从逐条提交转变为批量缓冲加延迟落盘——这正是“写入悬挂”技术的核心思路。让弹幕先进入内存队列，积攒到一定数量后统一通过insertMany写入数据库，同时配合TTL索引自动清理过期数据，省去手动删库的麻烦。

• 在开发或测试环境下，直接关闭journal: true；生产环境可设置为journal: false，并结合副本集多数写入机制来保障持久性
• 禁用writeConcern的等待确认（例如设为{w: 0}），由应用层负责重试逻辑
• 不要对content字段建立全文索引——弹幕搜索交由ES或向量数据库处理，MongoDB仅作为可靠的临时存储

用 bulkWrite + 内存队列实现悬挂写入

无需手写线程池或用Redis作为中间队列，那样过于复杂。在Node.js环境下，直接使用stream.Readable搭配bulkWrite更为轻量高效：

const buffer = [];
setInterval(async () => {
  if (buffer.length === 0) return;
  try {
    await db.collection('danmaku').bulkWrite(
      buffer.map(msg => ({
        insertOne: {
          document: {
            ...msg,
            ts: new Date(),
            _id: new ObjectId()
          }
        }
      })),
      { ordered: false } // 允许部分失败，不中断整个批次
    );
    buffer.length = 0; // 清空
  } catch (e) {
    console.error('bulkWrite failed:', e);
    // 失败时保留 buffer，下次重试（注意防重复）
  }
}, 100); // 每100ms flush 一次

几个关键要点：

• ordered: false 是必需的——某条弹幕字段非法（例如content超长）不应阻塞整批写入
• 缓冲区大小建议设置硬上限（如if (buffer.length > 500) buffer.shift()），防止内存溢出
• 每条msg必须携带唯一_id，否则bulkWrite会自动生成，导致无法去重

如何让弹幕查得快、删得准？

查询弹幕并非检索历史记录，而是查找“最近60秒的活跃弹幕”，因此不能依赖_id排序——ObjectId的时间戳精度仅有秒级，且写入时间不等于显示时间。正确做法是：

• 写入时显式记录毫秒级ts字段，并建立复合索引：db.danmaku.createIndex({ roomId: 1, ts: -1 })
• 查询时使用find({ roomId: "123", ts: { $gt: new Date(Date.now() - 60 * 1000) } }).limit(200)
• 删除旧数据利用TTL索引：db.danmaku.createIndex({ ts: 1 }, { expireAfterSeconds: 3600 })，1小时后自动清理，比定时任务更稳定

注意：expireAfterSeconds仅作用于单字段，不能用在{ roomId: 1, ts: 1 }复合索引上；TTL删除是后台线程异步执行，不保证精确到秒，但对弹幕这种弱时效性数据完全够用。

为什么不用 changeStream 实时推送？

许多人想用changeStream将新弹幕推送给客户端，实际会遇到两个陷阱：

• changeStream本身存在延迟（通常100–500ms），不如直接通过WebSocket + 内存广播快速
• 它依赖oplog，而oplog大小固定，默认仅为磁盘空间的5%，弹幕高频写入极易撑爆，触发OplogTruncation导致流中断

更合理的分层架构是：写入走悬挂bulkWrite → 内存缓存最近200条弹幕 → 新连接直接拉取缓存 + 订阅Redis Pub/Sub做增量同步。在此模式下，MongoDB仅作为最终一致的持久化底座，不参与实时链路。

真正容易被忽视的是buffer的生命周期管理——它既不能跨进程共享（Cluster模式下每个worker都需要独立buffer），也不能依赖GC自动回收（V8不保证及时）。必须通过process.on('SIGTERM', flushAndExit)实现优雅退出，否则进程被杀死时，buffer里数百条弹幕就会丢失。