MongoDB bulkWrite多进程并发更新同一文档的更新丢失问题求助

核心原因：无版本控制的「最后写入获胜」导致丢失更新 #

MongoDB 默认采用「最后写入获胜」的策略，且未内置乐观锁机制（需显式启用）。当两个进程同时针对同一文档的不同子树执行updateOne时，会出现以下场景：

1. 两个进程均读取到文档的同一初始版本（记为V0）
2. 进程A修改文档中subtreeId=X的子树，生成新版本V1并写入
3. 进程B基于V0版本修改subtreeId=Y的子树，生成版本V1并写入——此时进程B的写入会完全覆盖进程A的修改，因为它是基于旧版本V0的修改结果，而非在V1的基础上做增量修改。

这种情况属于典型的丢失更新问题，本质是并发写入未基于文档最新版本操作。

验证方式：查看MongoDB oplog #

通过查看MongoDB的操作日志（oplog），可以看到两个进程的update操作记录，后执行的操作会覆盖先执行的修改，因为它未合并已有变更，而是直接基于旧版本生成新的文档状态。

解决方案 #

1. 启用乐观锁机制 #

在文档中添加版本控制字段（如__v），每次更新时匹配当前版本，更新时同时递增版本号：

# 示例：带乐观锁的updateOne
result = db.collection.updateOne(
    {
        '_id': 'ABC12345',
        'idents.tree.subtreeId': 'X',
        '__v': current_version  # 读取文档时获取的当前版本
    },
    {
        '$set': {'idents.$.tree.entry': new_dict_A},
        '$inc': {'__v': 1}
    }
)
# 如果modifiedCount为0，说明版本冲突，需重新读取最新版本后重试
if result.modified_count == 0:
    # 重试逻辑
    pass

2. 使用原子数组更新+冲突重试 #

MongoDB的$操作符能保证单个updateOne操作的原子性（匹配+修改子树的过程是原子的），但无法解决跨进程的覆盖问题。结合findOneAndUpdate返回更新后的文档，验证修改是否生效：

updated_doc = db.collection.findOneAndUpdate(
    {'_id': 'ABC12345', 'idents.tree.subtreeId': 'X'},
    {'$set': {'idents.$.tree.entry': new_dict_A}},
    return_document=pymongo.ReturnDocument.AFTER
)
# 检查updated_doc中目标子树的entry是否为预期值，否则重试

3. 应用层串行化同一文档的更新 #

通过分布式锁（如Redis锁）对同一_id的文档更新进行串行控制，确保同一时间只有一个进程能修改该文档，从根源避免并发冲突。

关键注意点 #

• bulkWrite的ordered: false参数仅影响同一批量内的操作执行顺序，不会改变跨进程的并发行为。
• MongoDB的文档级锁（WiredTiger引擎）仅保证同一时间只有一个写入操作能修改文档，但不保证写入基于最新版本——锁只是防止同时写入，无法解决先后读取旧版本、后写入覆盖先写入的丢失更新问题。

内容的提问来源于stack exchange，提问作者Markus Müller