error-handling - 检测 .NET ChangeFeed 客户端库中的限制 (HTTP 429)

Question

在侦听 .NET 应用程序中的更改源更改时，在集合的高使用率高峰期间，对 CosmosDB 的请求可能会受到限制（HTTP 响应 429）。

适用于 .NET 的 CosmosDB 更改源客户端有 3 种风格：

1. 原文：Microsoft.Azure.DocumentDB.ChangeFeedProcessorv1.x。

2. 它的v2.x 继任者与 API 兼容，但对代码进行了彻底的更改。

3. 当前的实现是Microsoft.Azure.Cosmosv3的一部分

这些版本中的哪一个（如果有）支持插入错误处理的方法（以发出有关它的自定义遥测数据）？

原始库在内部实现了重试HTTP 429，我无法找到一种方法来挂钩重试机制。

Answer 1

这些库在延迟或速度方面没有 SLA 或保证。因为延迟或速度还受到用于处理这些更改的代码和部署它的基础设施（以及位置和网络延迟等因素）的影响。

唯一的保证是“至少一次”交付更改，只要容器可用并且有足够的预置吞吐量来服务请求。

这意味着变更馈送处理器将不断重试，试图履行交付变更的保证。如果容器被限制，它将继续尝试直到成功。无法保证您需要多长时间才能获得更改。

Cosmos DB 服务在返回 429（Throttle）时还会返回一个标头，指示何时需要重试请求，因此更改馈送处理器将遵守此等待时间并重试。

如果请求是遥测，可在Azure 诊断中查看，您可以在那里查看限制，甚至可以按用户代理进行筛选，以确定哪个应用程序正在接收它们。