在创建/更新文档与Cosmos DB Change Feed处理器拾取文档之间的“正常”延迟是多少？
我们执行的某些操作分为两个阶段：创建，然后在几毫秒后更新。
我知道更改馈送中只会显示文档的最新版本。但是，如果更改提要超级快，那么我将处理两个版本的文档。 RU使用量超出了必要，因为我只关心“最终”版本。
当然，我会设计处理器，以使其不在乎。当然，我怀疑是否有固定的保证。但是我 am 仍然很好奇，想知道以前是否有人有过任何经验（并关注此特定细节）。再过几周，我也许也可以发表自己的经历。
编辑：四处寻找，发现了FeedPollDelay。默认情况下看起来是5秒。因此，我想答案是“延迟/延迟是我想要的任何延迟”。就RU的使用而言，这很方便，但由于它是轮询体系结构，因此让人有些失望。虽然有道理：）
答案 0 :(得分：2)
您的问题实际上有两个方面。更改Feed是Cosmos DB中的一项功能，可在更改发生时发布更改，如here所述：
更改日志中仅包含给定项目的最新更改。中间更改可能不可用。
因此，如果在检查更改之间进行插入和更新操作，则可能会得到更新版本，而不是2个单独的更改。
另一方面，似乎您正在使用更改提要处理器，该库是一个可以帮助您使用此终结点的库（它是several available options之一）。正如您所提到的，CFP库在后台充当轮询机制：
ProcessChangesAsync实现，因此从开发人员的角度来看，它就像是推送模型。ProcessChangesAsync实施完成后，它将立即轮询以进行更多更改，没有延迟。FeedPollTime，然后再次轮询。这个区别很重要，因为如果您的更改是连续的，那么更改检测的唯一延迟就是您的ProcessChangesAsync实现可以处理它们的速度。