批量写入Serverless模式Cosmos返回429错误解决方案咨询

根因说明 #

这个问题不属于数据库创建时的配置遗漏，核心原因是当前业务写入模式和Cosmos DB Serverless的特性不匹配：Serverless模式默认有5000 RU/s的吞吐量硬上限，你每小时一次性批量写入属于典型的短时间突发高吞吐请求，峰值超过上限就会触发429限流。

分区策略也有可能放大这个问题：如果分区键选择不合理，比如所有批量写入的数据都命中同一个逻辑分区，那么即使总RU没有达到5000上限，也可能触发单个物理分区的吞吐量限流（单物理分区RU上限通常为10000 RU/s，部分场景下更低）。 #

可行解决方案 #

1. 调整部署模式适配突发写入特性 #

• 切换为自动缩放吞吐量模式：该模式支持设置RU上下限，你可以将下限设置为最低100 RU（覆盖非写入时段的极低请求消耗），上限调整到满足单次批量写入的吞吐量需求，整体成本和Serverless模式接近，但没有Serverless的固定RU硬上限，完美适配周期性突发写入场景。
• 申请提升Serverless RU上限：如果不想切换部署模式，可以提交工单申请将你的Serverless账号的RU/s上限调整到更高值，满足峰值写入需求。

2. 优化写入逻辑平滑吞吐消耗 #

• 拆分批量写入请求：不要一次性提交5807行的大批次写入，拆分为每批100~200行的小批次，批次之间增加适当的等待间隔，将峰值吞吐平摊到更长的时间窗口，避免短时间占满所有RU。
• 使用SDK原生批量操作能力：Cosmos DB各语言SDK都内置了批量操作支持，会自动根据当前可用RU调整请求发送速率，自带429重试逻辑，比自行实现的批量写入RU利用率更高、消耗更低。
• 新增指数退避重试逻辑：所有写入请求遇到429错误时，按照响应头返回的Retry-After值等待后再重试，避免无效请求持续占用吞吐量。

3. 优化分区策略降低单分区压力 #

• 选择高基数分区键：确保批量写入的数据均匀分散到多个逻辑分区，避免所有写入请求都落到同一个物理分区触发分区级限流，比如可以使用数据唯一ID、时间戳+业务标识的组合字段作为分区键。
• 乱序发送批量请求：如果业务不需要严格保证写入顺序，可以将批量数据按分区键打散后再发送，进一步均衡各个分区的吞吐消耗。

你可以先在Azure门户的Cosmos DB指标面板，查看429错误的类型，如果是账号级限流说明是总RU上限不足，如果是分区级限流则优先排查分区键设计问题。

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