Cosmos DB Change Feed-什么是延遲/延遲？

Question

創建/更新文檔與Cosmos DB Change Feed處理器接收文檔之間的“正常”延遲是多少？

我們執行的某些操作分為兩個階段：創建，然后在幾毫秒后更新。

我知道更改提要中只會顯示文檔的最新版本。 但是，如果更改提要超級快，那么我將處理兩個版本的文檔。 RU使用量超出了必要，因為我只在乎“最終”版本。

當然，我會設計處理器，以便它不在乎。 當然，我懷疑是否有固定的保證。 但是我仍然很好奇，想知道以前是否有人有過經驗（並注意過這一特定細節）。 再過幾周，我也許也可以發表自己的經歷。

編輯 ：挖掘，我發現FeedPollDelay。 默認情況下看起來是5秒。 因此，我想答案是“延遲/延遲是我想要的任何延遲”。 就RU的使用而言，這很方便，但由於它是輪詢體系結構，因此讓人有些失望。 雖然有道理:)

Answer 1

您的問題實際上有兩個方面。 更改飼料是在宇宙DB功能，因為它們發生，將發布變更，如所描述這里雖然：

更改日志中僅包含給定項目的最新更改。 中間更改可能不可用。

因此，如果在檢查更改之間進行插入和更新操作，則可能會得到更新版本，而不是2個單獨的更改。

另一方面，似乎您正在使用Change Feed Processor，這是一個可以幫助您使用此終結點的庫（它是幾個可用選項之一 ）。 正如您提到的，CFP庫在幕后充當了一種輪詢機制：

1. 它輪詢更改並將其發送到您的ProcessChangesAsync實現，因此從開發人員的角度來看，它感覺像是推送模型。
2. 在ProcessChangesAsync實現完成后，它將立即輪詢以獲取更多更改， 而不會延遲 。
3. 如果還有更多更改，則返回到＃1。 如果沒有更多更改，它將按您描述的那樣保存配置的FeedPollTime ，然后再次輪詢。

這種差異很重要，因為如果您的更改是連續的，那么更改檢測的唯一延遲就是您的ProcessChangesAsync實現可以處理它們的速度。