Cosmos DB 更改源 - 延迟/延迟是多少？

Question

创建/更新文档与 Cosmos DB 更改源处理器拾取文档之间的“正常”延迟是多少？

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

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

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

编辑：四处挖掘，我发现了 FeedPollDelay。默认情况下看起来是 5 秒。所以我想答案是“延迟/延迟是我想要的”。这在 RU 使用方面很方便，但有点令人失望，因为它是一个轮询架构。不过有道理:)

Answer 1

你的问题实际上有两个方面。更改源是 Cosmos DB 中的一项功能，它将在发生更改时发布更改，如下所述：

更改日志中仅包含给定项目的最新更改。中间更改可能不可用。

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

另一方面，您似乎正在使用更改源处理器，它是一个可以帮助您使用此端点的库（它是几个可用选项之一）。正如您所提到的，CFP 库在幕后充当轮询机制：

1. 它会轮询更改并将其发送到您的ProcessChangesAsync实现，因此从开发人员的角度来看，它感觉就像是推送模型。
2. 实施完成后ProcessChangesAsync，它将立即轮询以获取更多更改，不会有任何延迟。
3. 如果有更多更改，则返回到#1。如果没有更多更改，它将保留FeedPollTime您所描述的配置，并再次轮询。

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