azure-cosmosdb - Cosmos DB Change Feed - 延迟/延迟是多少？

Question

从创建/更新文档到 Cosmos DB Change Feed 处理器接收它之间的“正常”延迟是多少？

我们做的一些操作是两阶段的:创建，几毫秒后更新。

我知道只有最新版本的文档才会出现在更改源中。但如果更改提要速度超快，我将最终处理文档的两个版本。双倍的 RU 使用量比必要的多，因为我只关心“最终”版本。

当然，我会设计我的处理器，让它不关心。当然，我怀疑是否有任何一成不变的保证。但是我 仍然很好奇，想知道以前是否有人有过任何经验(并注意过这个特定的细节)。几周后，我或许也可以发布自己的体验。

编辑:四处挖掘，我发现了 FeedPollDelay。默认情况下看起来像 5 秒。所以我想答案是“延迟/延迟是我想要的”。这在 RU 使用方面很方便，但由于它是轮询架构而略微令人失望。虽然有道理:)

Answer 1

您的问题实际上有两个方面。 Change Feed 是 Cosmos DB 中的一项功能，它将在发生更改时发布更改，如所述 here虽然:

Only the most recent change for a given item is included in the change log. Intermediate changes may not be available.

因此，如果您的插入和更新操作发生在检查更改之间，您将获得更新版本而不是 2 个单独的更改。

另一方面，您似乎正在使用 Change Feed Processor，这是一个帮助您使用此端点的库(它是 several available options 之一)。正如您所提到的，CFP 库在后台用作轮询机制:

1. 它会轮询更改并将其发送到您的 ProcessChangesAsync 实现，因此从开发人员的角度来看，它感觉像是一种推送模型。
2. ProcessChangesAsync 实现完成后，它将立即轮询更多更改，没有延迟。
3. 如果有更多的变化，它会回到#1。如果没有更多更改，它将按照您描述的那样在配置的 FeedPollTime 内保持不变，然后再次轮询。

这种差异很重要，因为如果您的更改是连续的，那么更改检测中的唯一延迟来自您的 ProcessChangesAsync 实现处理它们的速度。