如何解决MongoDB中文档的并发读写更新问题？

1. 乐观锁（推荐，无锁阻塞） #

这是应对这类并发问题最常用的方案，核心逻辑是把时间戳作为更新条件，只有当数据库中存储的时间戳与你读取到的完全一致时，才执行更新操作。如果条件不匹配，说明已有其他实例完成了更新，本次操作直接失败，需要重新读取最新文档后重试。

举个SQL场景的示例：

UPDATE documents 
SET content = ?, updated_at = CURRENT_TIMESTAMP 
WHERE id = ? AND updated_at = ?;

执行后检查影响行数：如果返回1，说明更新成功；如果返回0，代表并发冲突，需要重新走「读取-检查-更新」的流程。

NoSQL比如MongoDB可以用原子更新命令实现：

db.documents.findOneAndUpdate(
  { _id: ObjectId("目标文档ID"), updated_at: ISODate("读取到的时间戳") },
  { $set: { content: "新内容", updated_at: new Date() } },
  { returnNewDocument: true }
)

如果返回null，说明冲突发生，触发重试逻辑即可。这种方式不需要加锁，性能表现更适合高并发场景，唯一需要处理的是冲突后的重试（建议设置有限次数，避免无限循环）。

2. 悲观锁（行级读锁） #

如果业务场景的并发冲突率极高，乐观锁重试次数过多影响性能，可以用悲观锁：在读取文档时就对该行/文档加排他锁，直到更新完成释放锁，其他实例在锁释放前无法读取或修改该文档。

SQL场景示例：

BEGIN TRANSACTION;
-- 读取时加排他锁，其他事务会阻塞直到锁释放
SELECT * FROM documents WHERE id = ? FOR UPDATE;
-- 执行时间戳检查和更新逻辑
UPDATE documents SET content = ?, updated_at = CURRENT_TIMESTAMP WHERE id = ?;
COMMIT;

注意：不同数据库的锁机制有差异，比如MySQL InnoDB引擎的FOR UPDATE会加行锁，其他事务读取该行时会阻塞。如果是分布式场景，也可以用Redis的SETNX实现分布式锁，但要注意处理锁超时、正确释放锁的问题。

3. 数据库原生原子更新 #

部分数据库支持直接将「检查+更新」合并为原子操作，不需要先读取再判断。比如SQL中可以直接依赖数据库生成时间戳，结合条件确保更新的原子性；NoSQL如Redis的HSETNX、MongoDB的原子修改命令，都能避免并发操作导致的覆盖问题。

关键注意事项 #

• 时间戳最好由数据库生成（比如SQL的CURRENT_TIMESTAMP、MongoDB的数据库端时间），避免客户端时钟不一致引发的判断错误。
• 乐观锁的重试逻辑要设置合理的次数上限，多次重试失败后可以返回错误给业务层，由上游处理冲突。

内容的提问来源于stack exchange，提问作者Ilya Chernomordik