本文介绍在高并发场景下，如何通过应用层文档锁机制避免 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<Types.ObjectId>();
private pendingWaits = new Map<Types.ObjectId, Array<NodeJS.Timeout>>();
private cleanupIntervals: NodeJS.Timeout[] = [];
readonly LOCK_TIMEOUT_MS = 60_000; // 60秒总等待超时
readonly POLL_INTERVAL_MS = 1000; // 每秒轮询一次
/**
* 尝试获取指定文档 ID 的锁；若已被占用，则等待直至释放或超时
*/
async acquire(_id: Types.ObjectId): Promise<void> {
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<void> {
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.save();
// ✅ 必须释放锁
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+save({ versionKey: true })）或原子操作（$push,$inc）替代部分逻辑。 -
Mongoose 内置优化：启用
versionKey: true并配合save({ timestamps: false })可辅助检测版本冲突，但无法完全替代锁——它仅能抛出错误，不能预防覆盖。
通过应用层文档锁，你能在不依赖数据库底层特性的前提下，有效保障并发写入的数据一致性，从根本上杜绝“Request 2 覆盖 Request 1 修改”的经典竞态问题。
