Cosmos DB高频并发单文档属性更新：Server-Side JS与.NET API选型咨询

嗨，针对你这个高频并发更新Cosmos DB文档属性的问题，我结合实际项目经验给你梳理下建议：

优先选择Server-Side JavaScript（存储过程/预定义函数）处理高频并发的单属性更新；竞态条件处理失败时，建议先添加带指数退避的重试机制，多次失败后再返回错误给调用方。

一、Server-Side JS vs .NET Cosmos DB API的选择 #

为什么优先选Server-Side JavaScript？ #

• 大幅减少网络开销，提升性能：高频并发场景下，用.NET API如果需要先读取文档状态再修改，至少要两次网络请求（读+写）。而存储过程直接在Cosmos DB服务端执行，一次请求就能完成「读取-修改-提交」的原子操作，延迟更低，能扛住更高的并发量。
• 利用单分区事务性降低竞态：Cosmos DB的存储过程在单个分区键范围内是ACID事务的——整个更新逻辑在服务端一次性执行，不会出现客户端读取文档后、提交修改前的时间窗口被其他请求抢占的情况，从根源上减少竞态冲突的概率。
• 集中化维护逻辑：把更新逻辑放在服务端，所有调用方（不管是.NET还是其他语言服务）都共用同一套规则，避免客户端各自实现带来的逻辑不一致，后续修改也更方便。

什么时候适合用.NET API？ #

如果你的更新逻辑非常简单（比如直接修改某个属性的固定值，不需要依赖文档当前状态），那.NET的PatchItemAsync方法其实也很高效——Patch操作是服务端直接执行的，不需要客户端先读取文档。但如果更新需要基于文档当前状态（比如给数值属性增量、根据现有值判断后修改），那还是存储过程更靠谱。

二、竞态条件处理失败：重试还是返回错误？ #

优先重试（带指数退避策略） #

• 适配业务允许的高频并发场景：既然是业务逻辑内的高频更新，冲突大多是瞬时的——比如两个服务同时更新同一文档，其中一个先成功，另一个因ETag不匹配失败。这时候重试几次，大概率能成功。
• 指数退避避免雪崩：不要无脑重试，要采用指数退避（比如第一次等100ms，第二次200ms，第三次400ms，最多重试3-5次），既能给Cosmos DB缓冲时间，也能减少和其他请求的冲突概率。
• 精准识别可重试错误：只对**乐观并发冲突（ETag不匹配）**进行重试，像网络故障、文档不存在这类错误直接返回，避免无效重试。

什么时候直接返回错误？ #

• 如果重试3-5次后仍然失败，说明可能存在持续的高并发冲突，或者业务逻辑不允许重复执行（比如扣减库存，重复重试可能导致多扣）。这时候应该返回错误给调用方，让调用方根据业务场景处理（比如提示用户稍后再试，或者触发补偿逻辑）。
• 如果是对一致性要求极高的场景（比如金融领域的精确记账），不允许重试带来的潜在风险，那也应该直接返回错误，由调用方决定下一步操作。

举个简单的存储过程示例（基于当前状态更新单个属性）：

function incrementCounter(docId, partitionKey) {
    var collection = getContext().getCollection();
    var response = getContext().getResponse();

    // 读取目标文档
    collection.readDocument(collection.getSelfLink() + "/docs/" + docId, { partitionKey: partitionKey }, function(err, doc) {
        if (err) throw err;

        // 增量更新属性
        doc.counter = (doc.counter || 0) + 1;

        // 提交更新
        collection.replaceDocument(doc._self, doc, function(err, updatedDoc) {
            if (err) throw err;
            response.setBody(updatedDoc);
        });
    });
}

这个存储过程在服务端原子执行「读-改-写」，能有效降低竞态概率，客户端只需要传递参数即可完成调用。

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