透過 Azure Cosmos DB 全域資料散發 - 運作原理

  • 發行項

適用於：NoSQL MongoDB Cassandra Gremlin Table

Azure Cosmos DB 是 Azure 的基礎服務，部署在全球所有的 Azure 區域，包括公用、主權、國防部 (DoD) 和政府雲端。

在技術上，Azure Cosmos DB 容器資料水平分割成多個複本集 (複寫寫入)，分散在每個區域。 複本集採用多數仲裁來永久認可寫入。

每個區域都包含 Azure Cosmos DB 容器的所有資料分割區，如果啟用多重區域寫入，則不但支援讀取，還支援寫入。 如果 Azure Cosmos DB 帳戶分散至 N 個 Azure 區域，則所有資料至少會有 N x 4 個複本。

在資料中心內，我們會在大規模戳記的機器上部署及管理 Azure Cosmos DB，每部都有專屬的本機儲存體。 在資料中心內，Azure Cosmos DB 會跨許多叢集進行部署，每個可能都會執行多個世代的硬體。 叢集內的機器通常散佈到 10 到 20 個容錯網域，以確保一個區域內的高可用性。 下圖顯示 Azure Cosmos DB 全域散發系統拓撲：

System Topology

Azure Cosmos DB 中的全域散發是周全的：只要按幾下滑鼠，或在程式設計中透過單一 API 呼叫，就能隨時新增或移除與 Azure Cosmos DB 資料庫建立關聯的地理區域。 Azure Cosmos DB 資料庫進而由一組 Azure Cosmos DB 容器組成。 在 Azure Cosmos DB 中，容器可作為散發和可擴縮性的邏輯單元。 您所建立的集合、資料表和圖形 (在內部) 只是 Azure Cosmos DB 容器。 容器完全與結構描述無關，提供查詢的範圍。 Azure Cosmos DB 容器中的資料都會在擷取時自動編製索引。 自動編製索引讓使用者在查詢資料時，省去管理結構描述或索引的麻煩，尤其在全球分散式設定中。

  • 在給定的區域中，容器內的資料依分割區索引鍵散發，索引鍵由您提供，並由基礎實體分割區在幕後管理 (「本機散發」)。

  • 每個實體分割區也跨地理區域複寫 (「全域散發」)。

當使用 Azure Cosmos DB 的應用程式在 Azure Cosmos DB 容器上彈性調整輸送量或耗用更多儲存空間時，Azure Cosmos DB 會透明地處理所有區域中的分割區管理作業 (分割、複製、刪除)。 不論是調整、散發或失敗，Azure Cosmos DB 都會繼續在容器內提供資料的單一系統映像，這些容器會跨任意數目的區域進行全域散發。

如下圖所示，容器內的資料沿著二個範圍散發：一個區域內和全球跨區域：

physical partitions

實體分割區由一群複本 (稱為「複本集」) 實作。 每部機器裝載數百個複本，而這些複本對應至一組固定流程內的各個實體分割區，如上圖所示。 對應到實體分割區的複本均會動態放置，並在區域中叢集和資料中心內的機器間進行負載平衡。

一個複本只會屬於一個 Azure Cosmos DB 租用戶。 每個複本都會裝載 Azure Cosmos DB 資料庫引擎的執行個體，其會管理資源及相關聯的索引。 Azure Cosmos DB 資料庫引擎會在 Atom-記錄-序列 (ARS) 型的類型系統上運作。 引擎沒有結構描述的概念，使得記錄的結構和執行個體值之間的界限變得模糊。 Azure Cosmos DB 會以有效率的方式，在擷取時自動為每個項目編製索引，藉以達到完全不會區分結構描述的論點，讓使用者能夠查詢他們的全域散發資料，而不需處理結構描述或索引管理。

Azure Cosmos DB 資料庫引擎會由元件所組成，其中包括實作數個協調基本項目、語言執行階段、查詢處理器，以及分別負責進行資料交易式儲存和編製索引的儲存體和編製索引子系統。 為了提供持久性和高可用性，資料庫引擎會在 SSD 上保存它的資料和索引，並且分別在複本集內的資料庫引擎執行個體之間複寫它。 更大的租用戶對應至更大規模的輸送量和儲存體，而且有更大或 (又) 更多的複本。 系統的每個元件都是完全非同步的，沒有任何執行緒會遭到封鎖，而且每個執行緒都會進行短暫存留的工作，而不會產生任何不必要的執行緒切換。 速率限制和背壓會在整個堆疊上，從許可控制連接到所有 I/O 路徑。 Azure Cosmos DB 資料庫引擎旨在利用細部並行，力求節省系統資源來提高輸送量。

Azure Cosmos DB 的全域散發依賴兩個關鍵抽象概念：「複本集」和「分割集」。 複本集是可用於協調的模組化 Lego 區塊，而分割集是一或多個地理位置分散之實體分割區的動態重疊。 若要了解全域散發的運作方式，我們需要了解這兩個關鍵抽象概念。

複本集

實體分割區會具體化為自我管理和動態負載平衡的複本群組，這些複本會分散到多個容錯網域，稱為複本集。 此集合會共同實作複寫的狀態機器通訊協定，以使實體分割區中的資料高度可用、耐久且一致。 複本集成員資格 N 是動態，隨著失敗、系統管理作業，以及重新建立/復原失敗複本的時間，在 NMin 和 NMax 之間不斷波動。 根據成員資格變更，複寫通訊協定也會重新設定讀取和寫入仲裁的大小。 為了均勻散發指派給特定實體分割區的輸送量，我們採用兩個構想：

  • 首先，處理領導者的寫入要求所花的成本，高於對跟隨者套用更新的成本。 同樣地，前端項目預算的系統資源會比實行項目還要多。

  • 其次，盡可能地使指定一致性層級的讀取仲裁僅由實行項目複本所組成。 除非必要，否則我們避免接觸領導者來處理讀取。 針對 Azure Cosmos DB 支援的五個一致性模型，我們在仲裁型系統中研究負載和容量的關聯性來利用一些構想。

分割集

組成一群實體分割區 (各來自每個已設定的 Azure Cosmos DB 資料庫區域)，以管理跨所有已設定區域所複寫的同一組索引鍵。 這個較高的協調基本類型稱為「分割集」，是地理分散動態重疊的實體分割區，負責管理一組特定的索引鍵。 雖然給定的實體分割區 (複本集) 以叢集為界限，但分割集可以橫跨叢集、資料中心及地理區域，如下圖所示：

Partition Sets

您可以將分割集想像為地理位置分散的「進階複本集」，其會由擁有相同索引鍵的多個複本集所組成。 與複本集類似，分割集的成員資格亦為動態，隨著隱含實體分割區管理作業對所指定分割集新增/移除新的分割區而波動 (例如，當擴增容器的輸送量、在 Azure Cosmos DB 資料庫中新增/移除區域，或發生失敗時)。 因為 (分割集的) 每個分割區在自己的複本集內管理分割集成員資格，成員資格完全分散且高度可用。 重新設定分割集期間，也會建立在實體分割區之間重疊的拓撲。 拓撲是根據來源與目標實體分割區之間的一致性層級、地理距離及可用網路頻寬而動態選取。

此服務可讓您使用單一寫入區域或多個寫入區域來設定 Azure Cosmos DB 資料庫，並根據選項，將分割集設定為只接受一個或接受所有區域中的寫入。 系統採用兩個層級的巢狀共識通訊協定，一個層級會在接受寫入之實體分割區複本集的複本內運作，而另一個層級會在分割集的層級上運作，以針對分割集內所有認可的寫入提供完整的順序保證。 這個多層式巢狀共識是實作嚴格 SLA 以提供高可用性，以及實作 Azure Cosmos DB 提供給其客戶一致性模型的關鍵。

衝突解決功能

我們對於更新傳播、衝突解決和因果追蹤的設計靈感來自先前在 epidemic 演算法 \(英文\) 和 Bayou \(英文\) 系統上的工作。 儘管構想的核心已存留並提供方便參考的架構來與 Azure Cosmos DB 系統設計溝通，但隨著我們將其套用到 Azure Cosmos DB 系統，它們也經歷了明顯的轉變。 這有必要，因為先前系統的設計既無資源控管，亦無 Azure Cosmos DB 運作所需的規模，也沒有可讓 Azure Cosmos DB 交付給客戶的功能 (例如限定過期一致性) 和嚴格又全面的 SLA。

回想一下，分割集散發至多個區域，並遵循 Azure Cosmos DB (多重區域寫入) 複寫通訊協定，在組成所指定分割集的實體分割區之間複寫資料。 每個實體分割區 (屬於分割集) 都會接受寫入，而且通常可為該區域的區域用戶端提供讀取。 區域內實體分割區所接受的寫入會被永久認可，並在將它們認可到用戶端之前，使其可在實體分割區內高度可用。 這些都是暫時性寫入，並會使用反熵通道傳播到分割集內的其他實體分割區。 用戶端可以藉由傳遞要求標頭來要求暫時性或認可的寫入。 反熵傳播 (包括傳播頻率) 是動態的，會以分割集的拓撲、實體分割區的區域性近接，以及所設定的一致性層級為根據。 在分割集內，Azure Cosmos DB 會遵循主要的認可配置，其中具有動態選取的仲裁程式分割區。 選取仲裁程式是動態的，而且是根據重疊拓撲重新設定分割集時不可或缺的一部分。 保證會將認可的寫入 (包括多列/批次更新) 進行排序。

我們採用已編碼的向量時鐘 (包含區域識別碼，以及分別對應到複本集和分割集上每個共識層級的邏輯時鐘)，以進行因果追蹤和版本向量來偵測及解決更新衝突。 拓撲和對等選取演算法旨在確保固定且最基本的儲存體，以及版本向量的最小網路額外負荷。 此演算法會保證嚴格的聚合屬性。

針對使用多個寫入區域設定的 Azure Cosmos DB 資料庫，系統提供許多彈性自動衝突解決原則，讓開發人員可從中選擇，包括：

  • 最後寫入者優先 (Last-Write-Wins，LWW)，預設使用系統定義的時間戳記屬性 (以時間同步時鐘通訊協定為基礎)。 Azure Cosmos DB 也可讓您指定任何其他自訂數值屬性以用來解決衝突。
  • 應用程式定義的 (自訂) 衝突解決原則 (透過合併程序來表示)，旨在以應用程式定義的語意調解衝突。 在伺服器端偵測到資料庫交易的支援下有寫入-寫入衝突時，就會叫用這些程序。 系統在認可通訊協定中保證合併程序只執行一次。 有幾個衝突解決範例可供您測試。

一致性模型

不論您使用單一或多個寫入區域來設定 Azure Cosmos DB 資料庫，都有五個定義明確的一致性模型供您選擇。 使用多個寫入區域時，一致性層級有幾個重點如下：

限定過期一致性保證自任何區域的最後一次寫入起算，所有讀取都在 K 個前置詞或 T 秒內。 此外，保證具有限定過期一致性的讀取單純且開頭一致。 反熵通訊協定會以速率限制的方式運作，並確保前置詞不會累積，而且不必在寫入上套用背壓。 工作階段一致性保證全球性的單純讀取、單純寫入、讀取您自己的寫入、讀取後接寫入，以及開頭一致。 如果資料庫設定為強式一致性，由於跨區域的同步複寫，不享有多個寫入區域的優點 (低寫入延遲、高寫入可用性)。

這裡描述 Azure Cosmos DB 中五個一致性模型的語意，而這裡以高階 TLA+ 規格從數學上描述。

下一步

接下來，了解如何使用下列文章來設定全域散發：