如何防止 MongoDB 中的 Mongoose 版本冲突与并发写覆盖问题

本文介绍在高并发场景下，如何通过应用层文档锁机制避免 Mongoose 数据被后写请求意外覆盖，解决“先读-后改-再存”导致的丢失更新（Lost Update）问题。

本文介绍在高并发场景下，如何通过应用层文档锁机制避免 Mongoose 数据被后写请求意外覆盖，解决“先读-后改-再存”导致的丢失更新（Lost Update）问题。

在基于 Mongoose 的 Node.js 应用里，如果多个请求同时读到同一份文档，各自改了不同字段，随后再分别保存——比如示例里的 read.push(user._id) 这种操作——就很容易踩中写覆盖（Write Race Condition）这个坑：后提交的那次保存，会把前一次已经生效的改动整个顶掉，结果就是数据被悄悄冲掉了。问题在于，MongoDB 原生并没有提供行级锁或悲观锁这类能力，像 PostgreSQL 里的 SELECT ... FOR UPDATE 也没有现成对应方案，所以并发控制这件事，必须在应用层自己搭出一套足够稳妥的机制。

✅ 推荐方案：轻量级内存文档锁（Application-Level Document Locking）

以下是一个生产可用的 TypeScript 实现，基于 Set 和 Map 管理文档锁状态，并提供超时等待与自动清理能力：

import { Types } from 'mongoose';

export class DocumentLocker {
private lockedIds = new Set();
private pendingWaits = new Map>();
private cleanupIntervals: NodeJS.Timeout[] = [];

readonly LOCK_TIMEOUT_MS = 60_000; // 60秒总等待超时
readonly POLL_INTERVAL_MS = 1000; // 每秒轮询一次

/**
 * 尝试获取指定文档 ID 的锁；若已被占用，则等待直至释放或超时
 */
async acquire(_id: Types.ObjectId): Promise {
if (this.lockedIds.has(_id)) {
await this.waitForUnlock(_id);
}
this.lockedIds.add(_id);
}

/**
 * 释放文档锁
 */
release(_id: Types.ObjectId): void {
this.lockedIds.delete(_id);
// 清理该 ID 对应的所有待唤醒定时器
const timers = this.pendingWaits.get(_id) || [];
timers.forEach(clearInterval);
this.pendingWaits.delete(_id);
}

/**
 * 内部等待逻辑：轮询检查锁是否释放
 */
private waitForUnlock(_id: Types.ObjectId): Promise {
return new Promise((resolve, reject) => {
let elapsed = 0;
const interval = setInterval(() => {
if (!this.lockedIds.has(_id)) {
clearInterval(interval);
resolve();
return;
}
elapsed += this.POLL_INTERVAL_MS;
if (elapsed >= this.LOCK_TIMEOUT_MS) {
clearInterval(interval);
reject(new Error(`Failed to acquire lock for ${_id} after ${this.LOCK_TIMEOUT_MS}ms`));
}
}, this.POLL_INTERVAL_MS);

const timers = this.pendingWaits.get(_id) || [];
timers.push(interval);
this.pendingWaits.set(_id, timers);
});
}
}

// 全局单例（根据部署模式可升级为 Redis 分布式锁）
export const locker = new DocumentLocker();

? 在业务逻辑中集成锁机制

将上述 locker 集成到你的路由处理器中，确保每次修改前先加锁、修改后及时释放：

exports.readInfo = async (req, res) => {
const user = req.user;
const data = req.data;
const docId = new Types.ObjectId(data._id);

try {
// ⚠️ 关键：获取文档锁（阻塞/超时等待）
await locker.acquire(docId);

const doc = await Doc.findOne({ _id: docId });
if (!doc) {
throw new Error('Document not found');
}

// 安全执行变更（此时无其他并发写入）
doc.infos[data.key][data.skey][data.i].read.push(user._id.toString());
doc.markModified(`infos.${data.key}.${data.skey}.${data.i}`);

await doc.sa ve();

// ✅ 必须释放锁
locker.release(docId);

res.status(200).end('success');
} catch (err) {
locker.release(docId); // 异常时也要释放锁，避免死锁
console.error('Locking error:', err);
res.status(500).json({ error: err.message });
}
};

⚠️ 注意事项与进阶建议

• 单进程适用性：当前实现基于内存，适用于单实例 Node.js 进程。若使用 PM2 Cluster 或多服务器部署，需替换为 Redis 分布式锁（如 redlock 或 ioredis 的 SET NX PX 命令）。
• 锁粒度控制：按 _id 锁定整个文档是安全但粗粒度的策略；若业务允许，可细化为字段级锁（如 infos.key.skey.i），但需更复杂的状态管理。
• 避免死锁：务必保证 acquire 和 release 成对调用，推荐使用 try...finally 或封装为资源管理函数。
• 性能权衡：锁会引入延迟，高频写场景建议结合乐观锁（versionKey + sa ve({ versionKey: true })）或原子操作（$push, $inc）替代部分逻辑。
• Mongoose 内置优化：启用 versionKey: true 并配合 sa ve({ timestamps: false }) 可辅助检测版本冲突，但无法完全替代锁——它仅能抛出错误，不能预防覆盖。

通过应用层文档锁，你能在不依赖数据库底层特性的前提下，有效保障并发写入的数据一致性，从根本上杜绝“Request 2 覆盖 Request 1 修改”的经典竞态问题。