为何带10分钟延迟的Cosmos DB Change Feed WebJob显示百万级滞后？

核心诱因与分析方向 #

1. 长时延迟导致租约进度停滞 #

当WebJob执行await Task.Delay(600000)（10分钟）时，Change Feed处理器的租约更新逻辑会暂停。滞后估算器依赖处理器上报的当前处理位置（租约文档中的ContinuationToken），若10分钟内无租约更新，估算器会以旧位置为基准，计算其与Cosmos DB最新写入位置的差值——哪怕这段时间仅新增少量记录，也会被误判为大量未处理积压。

2. 估算器统计范围与实际处理范围不匹配 #

滞后估算器默认基于容器总写入量减去处理器已确认处理量计算，而非实时统计当前未处理的目标记录数：

• 若WebJob仅处理特定分区或过滤后的记录，估算器会将同期容器内的其他写入（无关业务的记录）也计入滞后值，导致数值虚高。
• 若租约文档中的ContinuationToken未正确更新，估算器会持续使用旧位置计算差值，进一步放大偏差。

3. 租约续租失效引发的分片误判 #

Change Feed处理器默认每30秒续租一次租约，若Task.Delay阻塞了处理器的工作线程，会导致租约续租失败，该处理器对应的分片会被标记为“未被处理”。此时估算器会将整个分片的历史未处理记录数（远大于实际待处理的100条）计入滞后值。

具体排查步骤 #

• 查看租约容器内对应WebJob的租约文档，检查ContinuationToken的更新时间：若延迟期间无更新，说明处理器停滞导致估算基准失效。
• 核对Cosmos DB容器在延迟时段的写入指标：查看“写入请求单位”统计，确认同期实际写入条数是否与估算的数百万量级匹配，若不匹配则说明统计范围不一致。
• 检查WebJob的处理器配置：确认FeedProcessingOptions中的LeaseRenewInterval、LeaseAcquireInterval等参数是否合理，避免延迟期间租约失效。
• 临时移除10分钟延迟代码，观察滞后估算值是否恢复正常：若恢复，即可确认延迟是直接诱因。

修复建议 #

• 重构延迟逻辑：不要在处理器主循环中添加长时延迟，改为每处理一批记录后添加短延迟，确保处理器能定期更新租约和ContinuationToken。
• 自定义估算逻辑：若WebJob仅处理特定范围的记录，在估算滞后值时加入相同的分区或过滤条件，排除无关写入的干扰。
• 优化租约配置：调整LeaseRenewInterval参数，确保即使存在短延迟，处理器仍能正常续租租约，避免分片被标记为未处理。

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