Azure Cosmos DB变更源处理器租赁容器请求量过高问题咨询

背景回顾 #

使用Azure Cosmos DB Change Feed Processor（CFP）处理单物理分区的监控容器，部署于AKS（.NET 8.0），初始配置2个Pod副本、租赁容器400 RU/s、轮询间隔5秒、批量大小10，出现租赁容器每分钟9万次请求及HTTP 429限流；减为1个Pod后请求降至每分钟2.34万次仍有429，调整轮询间隔10秒、批量大小1000、租赁配置（获取间隔30秒、续约30秒、过期90秒）后请求量下降但仍增长。

1. 单副本管理单个物理分区时，租赁容器每秒350次请求是否正常？仍出现429错误是否符合预期？ #

• 每秒350次请求完全不正常。正常情况下，单个租赁文档的操作（续约、状态检查）频次极低：按30秒续约间隔计算，每秒仅约0.03次续约请求，加上少量租赁状态校验，总请求量应控制在每秒个位数级别。
• 仍出现429不符合预期。400 RU/s的吞吐量足以支撑正常租赁操作（单次租赁续约/获取请求约消耗1-2 RU），当前请求量远超合理范围，说明配置仍存在激进参数，或是CFP内部存在异常轮询/竞争逻辑。

2. 是否需要调整WithPollInterval、WithMaxItems、WithLeaseConfiguration参数？若需要，如何调优以降低请求量且不影响性能？ #

需要针对性调整，具体建议如下：

• WithLeaseConfiguration（核心调优项）：
  • AcquireInterval（租赁获取间隔）：单副本+单物理分区场景下，无需频繁尝试获取新租赁，建议调至60秒，避免无意义的租赁竞争查询。
  • RenewInterval（租赁续约间隔）：从30秒调至60秒，减少续约请求频次；同时将LeaseExpirationInterval（租赁过期时间）设为续约间隔的3倍（即180秒），确保续约窗口足够，避免因网络延迟导致租赁失效。
• WithPollInterval（变更源轮询间隔）：该参数控制CFP检查变更源是否有新数据的间隔，单分区场景下无需高频轮询，建议从10秒调至30-60秒。若业务对数据延迟敏感，可维持10秒，但需确认该参数不会触发额外租赁相关请求。
• WithMaxItems（批量大小）：当前1000的配置已合理，只要业务处理能力允许（内存、下游吞吐量），可保持或适当增大，减少变更源的请求次数（该参数不直接影响租赁容器请求）。
• 额外检查：确认租赁容器是否开启自动清理过期租赁功能，避免无效租赁文档占用资源；同时可临时提升租赁容器吞吐量至1000 RU/s，验证调优后请求量下降后是否仍需400 RU/s。

3. 单个物理分区场景下，部署2个Pod副本是否有意义？是否能提升容错性，还是仅增加Cosmos DB压力与租赁流量？ #

• 部署2个Pod副本无实际意义，仅会增加Cosmos DB压力与租赁流量。
• 原因：Cosmos DB Change Feed的物理分区是独占式分配的，单个物理分区只能被一个CFP实例（Pod）处理。第二个Pod会持续尝试竞争唯一的租赁文档，产生大量无效的租赁查询/获取请求，直接导致租赁容器请求量暴增（如初始场景的每分钟9万次请求）。
• 容错性方面：单个Pod故障时，AKS的副本集机制会自动重启Pod，或通过HPA快速拉起新Pod，CFP会在租赁过期后自动接管分区，该过程的延迟（取决于租赁过期时间）完全可接受，无需通过双副本持续竞争实现“即时容错”。

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