Azure CosmosDB 在一致性(Consistency)可用性(Availability)和性能(Performance)之間的權衡

Azure CosmosDB在一致性、可用性和性能之間的權衡

個人感覺這個概念類似于分布式系統中的CAP原理:

CAP原則是指在分布式系統中，一致性、可用性和分區容忍度不能兼得。

Azure CosmosDB有五個一致性級別。從數據一致性的角度來看，我們按照一致性最強到最低的順序排列如下:

1.強(強一致性)

2.有限的陳舊

3.會話(會話一致性)

4.一致前綴(一致前綴)

5.終極一致性(最終一致性)

每個級別都有一致性、可用性和性能之間的權衡，并有SLA(服務級別協議)。

一致性級別和延遲

對于所有一致性級別，第99個百分位數的讀取延遲小于10毫秒。這個讀操作的延遲由SLA保證。

在第99百分位，所有一致性級別的讀取延遲始終保證小于10毫秒。SLA支持這種讀取延遲。

在第50百分位，平均讀取延遲小于2毫秒。第50個百分位的平均讀取延遲通常為2毫秒或更少

跨多個Azure區域強(強一致性)配置的CosmosDB賬戶不在上述性能指標范圍內。

對于所有一致性級別的寫入，第99個百分點的延遲小于10毫秒。這個寫操作的延遲也由SLA保證。

在第99個百分點處，所有一致性級別的寫入延遲始終保證小于10毫秒。SLA支持這種寫入延遲。

平均寫入操作，第50個百分位數的延遲小于5毫秒。

當Azure CosmosDB帳戶跨越Azure數據中心區域并且配置了強一致性場景時，

寫入延遲保證小于兩個最遠Azure區域之間往返時間(RTT)的兩倍，加上第99個百分位數中的10毫秒。

這里有一個例子。假設我們創建了一個Azure CosmosDB賬戶，橫跨Azure新加坡數據中心、Azure香港數據中心和Azure東京數據中心，配置了一個強一致的場景。

寫入延遲=任何一個地區之間往返時間(RTT)的兩倍=Azure Singapore數據中心lt；gt；東京Azure數據中心之間往返時間(RTT)的兩倍，加上第99百分位的10毫秒。

因為在分布式系統中，對于強寫的場景，需要在所有分布式節點都進行了寫操作后，才能確定執行成功。

此選項當前處于預覽狀態。

準確的往返時間，RTT)取決于光速和Azure網絡拓撲。Azure network不會為任何兩個Azure區域之間的RTT提供任何延遲SLA。

對于您的Azure Cosmos帳戶，復制延遲將顯示在Azure門戶中。您可以使用Azure portal來監控與您的帳戶相關聯的各個區域之間的復制延遲。

一致性級別和吞吐量

同樣的請求單元(CosmosDB的性能指標，后面章節會詳細介紹)，Session(會話一致性)、Consistent prefix(一致性前綴)和final consistency(最終一致性)讀操作的吞吐量是Strong(強一致性)和有界一致性的兩倍。

對于給定類型的寫操作(如插入、替換、更新插入和刪除)，所有一致性級別在同一請求單元下具有相同的寫吞吐量。

一致性扇區和數據持久性

在Azure多區域分布式數據庫環境中，當發生區域服務中斷時，一致性級別與數據持久性有直接關系。在制定業務連續性計劃時，有必要知道應用程序在中斷事件后完全恢復之前的最大可接受時間。完全恢復一個應用程序所需的時間稱為恢復時間目標(RTO)。此外，還需要知道從中斷事件中恢復時，應用程序可以容忍最新數據更新丟失的最長時間。您可以承受的更新丟失的時間限制稱為恢復點目標(RPO)。

下表定義了發生區域性服務中斷時一致性模型和數據持久性之間的關系。需要注意的是，在分布式系統中，由于CAP定理的存在，即使一致性很高，也不可能存在RPO和RTO為零的分布式數據庫。

K=一個項目的“k”個版本(更新)的數量。

T=時間“T”，自上次更新以來的時間間隔。

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發表后的30日內與ESG跨境電商聯系。