Azure Cosmos DB批量插入延续令牌获取及CSV导入超时问题咨询

让我来帮你解决这两个Cosmos DB的问题：

延续令牌本质是Cosmos DB用来标记未完成操作进度的标记，当你的批量INSERT因为限流（429错误）、批次大小限制或网络中断等原因没一次性完成时，SDK会返回这个令牌，让你能从断点继续操作。

以常用的.NET SDK为例，使用TransactionalBatch做批量INSERT时，若操作未完全执行，你可以从返回结果里提取延续令牌：

var batch = container.CreateTransactionalBatch(new PartitionKey("目标分区键值"));
foreach (var doc in 当前批次文档)
{
    batch.CreateItem(doc);
}

var response = await batch.ExecuteAsync();

// 若操作未完成，获取延续令牌用于后续续传
if (!response.IsSuccessStatusCode && !string.IsNullOrEmpty(response.ContinuationToken))
{
    string continuationToken = response.ContinuationToken;
    // 后续执行时传入令牌，SDK会自动从断点继续处理剩余文档
    var nextBatch = container.CreateTransactionalBatch(new PartitionKey("目标分区键值"))
        .WithContinuationToken(continuationToken);
    var nextResponse = await nextBatch.ExecuteAsync();
}

其他SDK（Java、Python等）的逻辑类似：执行批量INSERT后，检查返回结果中的延续令牌字段，若存在则保存并用于下一次批量请求，直到所有文档插入完成。

注意：延续令牌仅对同一分区键的批量操作有效，跨分区的批量操作需要按分区键分组后分别处理。

你遇到的存储过程超时问题很典型——Cosmos DB存储过程默认执行超时是5秒，最大也只能调到10秒，而且它是单分区执行的，根本没法处理10000条这么大的批量操作，超时后自然触发原子回滚，导致一条文档都没创建。

结合你之前用延续令牌成功更新数千条文档的经验，我推荐以下解决方案：

核心思路：客户端批量操作+分区键分组+延续令牌重试 #

• 解析CSV并按分区键分组：先把CSV解析成Cosmos DB文档对象，再按文档的分区键值分组。因为Cosmos DB的原子批量操作（Transactional Batch）仅支持单分区内的原子性，分组后每个分区的操作能保证原子性；如果不需要全局原子（大部分CSV上传场景不需要），这个方案完全够用。
• 分批次执行Transactional Batch INSERT：对每个分区键组的文档，分成小批次（比如每次100-200条，具体数量根据文档大小调整，确保单批次RU消耗不超过容器可用RU）：
  • 若批次执行成功，直接进入下一批；
  • 若遇到限流或未完成，提取延续令牌，用令牌继续执行剩余文档；
  • 若批次执行失败（非限流），该分区的这批文档会原子回滚，你可以记录错误后重试。
• 临时提升RU吞吐量：上传期间可以临时把容器RU调高（比如从400调到10000），避免频繁429限流拖慢速度，完成后再调回原RU值，能大幅提升上传效率。
• 并行处理多分区：如果文档分布在多个分区键上，可以在客户端并行处理不同分区的批次，进一步加快上传速度。

为什么这个方案比存储过程好？ #

• 摆脱了存储过程的超时限制：客户端操作可以分批多次执行，不会因为单批次超时导致全部回滚；
• 自动适配限流：利用延续令牌或SDK内置重试机制处理429错误，不用自己写复杂的重试逻辑；
• 灵活性更高：可根据文档大小、容器RU动态调整批次大小，适配不同场景；
• 保留原子性：单分区内的批次操作依然是原子的，满足你的需求。

内容的提问来源于stack exchange，提问作者Arthur Hebert-Ryan