讀取 Azure Cosmos DB 變更摘要
適用於：
NoSQL
您可以透過推送模型或提取模型來使用 Azure Cosmos DB 變更摘要。 透過推送模型，變更摘要處理器會將工作推送至具有處理此工作商務邏輯的用戶端。 然而，變更摘要處理器內將處理檢查工作和儲存上次處理工作狀態的複雜項目。
透過提取模型，用戶端必須從伺服器提取工作。 在此情況下，用戶端不僅具有處理工作的商務邏輯，而且也會儲存上次處理工作的狀態、處理多個用戶端平息處理工作的負載平衡，以及處理錯誤。
若從 Azure Cosmos DB 變更摘要讀取，我們通常建議使用推送模型，因為您不需要擔心下列事項：
- 輪詢變更摘要，以用於未來變更。
- 儲存上次處理之變更的狀態。 如果您要從變更摘要處理器讀取，狀態會自動儲存於租用容器中。
- 在取用變更的多個用戶端之間進行負載平衡。 例如，如果有一個用戶端趕不上處理變更，而另一個具有可用容量。
- 處理錯誤。 例如，自動重試失敗的變更，系統無法在程式碼中有未處理的例外狀況或暫時性網路問題之後正確處理這類變更。
大部分使用 Azure Cosmos DB 變更摘要的案例都將使用其中一個推送模型選項。 不過，在某些情況下，您可能會想要對提取模型進行額外的低層級控制。 包括：
- 透過特定分割區索引鍵讀取變更
- 控制用戶端接收要處理變更的步調
- 執行變更摘要中的現有資料一次性讀取 (例如，執行資料移轉)
透過推送模型讀取變更摘要
使用推送模型，是從變更摘要中讀取的最簡單方式。 有兩種方式可讓您使用推送模型以從變更摘要中進行讀取：Azure Functions Azure Cosmos DB 觸發程序與變更摘要處理器。 Azure Functions 會在幕後使用變更摘要處理器，因此，這兩者讀取變更摘要的方式類似。 將 Azure Functions 視為變更摘要處理器的主控平台，而不是讀取變更摘要的完全不同方式。
Azure Functions
如果您剛開始使用變更摘要，Azure Functions 就是最簡單的選項。 因其簡潔性之故，其也是大多數變更摘要使用案例的建議選項。 當您建立適用於 Azure Cosmos DB 的 Azure Functions 觸發程序時，您會選取要連線的容器，如此即會在容器中有所變更時觸發 Azure 函式。 由於 Azure Functions 會在幕後使用變更摘要處理器，因此，其會自動跨容器的分割區平行處理變更。
使用 Azure Functions 進行開發是一種簡單的體驗，而且可能為比自行部署變更摘要處理器更快。 您可以使用 Azure Functions 入口網站來建立觸發程序，或使用 SDK 以程式設計方式來建立。 Visual Studio 和 VS Code 提供撰寫 Azure Functions 的支援，您甚至可以使用 Azure Functions CLI 進行跨平台開發。 您可以在電腦上撰寫和偵錯程式碼，然後只需按一下按鈕即可部署該功能。 若要深入了解，請參閱使用 Azure Functions 的無伺服器資料庫計算和搭配使用變更摘要與 Azure Functions 文章。
變更摘要處理器程式庫
變更摘要處理器讓您更能控制變更摘要，而且仍會隱藏大多數的複雜度。 變更摘要處理器程式庫會遵循觀察者模式，而您的處理函式會由程式庫呼叫。 變更摘要處理器將自動檢查是否有變更，如果發現變更，則會將這些變更推送到用戶端。 如果您有高輸送量的變更摘要，則可將多個用戶端具現化，以讀取變更摘要。 變更摘要處理器會自動將負載分散到不同的用戶端。 您不需要在多個用戶端之間實作負載平衡的邏輯，也不需實作任何邏輯來維護租用狀態。
變更摘要處理器保證全部變更會傳遞「至少一次」。 換句話說，如果您使用變更摘要處理器，則將針對變更摘要中的每個項目成功呼叫您的處理函式。 如果處理函式中的商務邏輯有未處理的例外狀況，失敗的變更將會重試，直到成功處理為止。 為了避免您的變更摘要處理器「停滯」持續重試相同變更，請在您的處理函式中新增邏輯，以便在發生例外狀況時，將文件寫入至無效信件佇列。 深入了解錯誤處理。
在 Azure Functions 中，適用於處理錯誤的建議都一樣。 您仍然應該在委派程式碼中新增邏輯，以便在發生例外狀況時，將文件寫入至無效信件佇列。 不過，如果您的 Azure 函式中有未處理的例外狀況，則產生例外狀況的變更將不會自動重試。 如果商務邏輯中有未處理的例外狀況，Azure 函式將會繼續處理下一個變更。 Azure 函式不會重試相同的失敗變更。
如同 Azure Functions，使用變更摘要處理器程式庫進行開發很容易。 不過，您必須負責為變更摘要處理器部署一部或多部主機。 主機是應用程式執行個體，會使用變更摘要處理器來接聽變更。 雖然 Azure Functions 具有自動調整功能，但您還是必須負責調整主機。 若要深入了解，請參閱使用變更摘要處理器。 變更摘要處理器程式庫是 Azure Cosmos DB SDK V3 \(英文\) 的一部分。
使用提取模型讀取變更摘要
變更摘要提取模型讓您能夠依自己的步調取用變更摘要。 變更必須由用戶端提出要求，而且不會自動輪詢變更。 如果您想要將上次處理的變更設定為永久「書籤」(類似於推送模型的租用容器)，您將必須儲存接續權杖。
使用變更摘要提取模型，您可以針對變更摘要取得更低階的控制。 使用提取模型讀取變更摘要時，您有三個選項：
- 讀取整個容器的變更
- 讀取特定 FeedRange 的變更
- 讀取特定分割區索引鍵值的變更
您可以在多個用戶端之間平行處理變更，就像使用變更摘要處理器一樣。 不過，提取模型不會自動處理用戶端之間的負載平衡。 當您使用提取模型來平行處理變更摘要時，您將先取得 FeedRanges 的清單。 FeedRange 會跨越分割區索引鍵值的範圍。 您將需要有協調器程序，才能取得 FeedRanges，並將其分散到您的機器中。 然後，您可以使用這些 FeedRanges，讓多部機器能夠以平行方式讀取變更摘要。
提取模型並未內建「至少一次」傳遞保證。 提取模型可讓您進行低階控制，以決定您想要如何處理錯誤。
Cassandra API 和 MongoDB API 中的變更摘要
變更摘要功能會呈現為適用於 MongoDB 的 API 中的變更資料流，並在適用於 Cassandra 的 API 中使用述詞進行查詢。 若要深入了解適用於 MongoDB 的 API 的實作詳細資料，請參閱 Azure Cosmos DB for MongoDB 中的變更資料流。
原生 Apache Cassandra 提供異動資料擷取 (CDC)，這是一種標示特定資料表以進行封存的機制，而且會在達到 CDC 記錄的可設定磁碟大小之後，拒絕那些資料表的寫入。 Azure Cosmos DB for Apache Cassandra 中的變更摘要功能可增強透過 CQL 使用述詞查詢變更的能力。 若要深入了解實作詳細資料，請參閱 Azure Cosmos DB for Apache Cassandra 中的變更摘要。
下一步
您現在可以在下列文章中繼續深入了解變更摘要：