Azure CosmosDB 在一致性(Consistency)可用性(Availability)和性能(Performance-ESG跨境

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

Azure CosmosDB在一致性、可用性和性能之間的權(quán)衡

個(gè)人感覺(jué)這個(gè)概念類(lèi)似于分布式系統(tǒng)中的CAP原理:

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

Azure CosmosDB有五個(gè)一致性級(jí)別。從數(shù)據(jù)一致性的角度來(lái)看，我們按照一致性最強(qiáng)到最低的順序排列如下:

1.強(qiáng)(強(qiáng)一致性)

2.有限的陳舊

3.會(huì)話(會(huì)話一致性)

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

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

每個(gè)級(jí)別都有一致性、可用性和性能之間的權(quán)衡，并有SLA(服務(wù)級(jí)別協(xié)議)。

一致性級(jí)別和延遲

對(duì)于所有一致性級(jí)別，第99個(gè)百分位數(shù)的讀取延遲小于10毫秒。這個(gè)讀操作的延遲由SLA保證。

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

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

跨多個(gè)Azure區(qū)域強(qiáng)(強(qiáng)一致性)配置的CosmosDB賬戶不在上述性能指標(biāo)范圍內(nèi)。

對(duì)于所有一致性級(jí)別的寫(xiě)入，第99個(gè)百分點(diǎn)的延遲小于10毫秒。這個(gè)寫(xiě)操作的延遲也由SLA保證。

在第99個(gè)百分點(diǎn)處，所有一致性級(jí)別的寫(xiě)入延遲始終保證小于10毫秒。SLA支持這種寫(xiě)入延遲。

平均寫(xiě)入操作，第50個(gè)百分位數(shù)的延遲小于5毫秒。

當(dāng)Azure CosmosDB帳戶跨越Azure數(shù)據(jù)中心區(qū)域并且配置了強(qiáng)一致性場(chǎng)景時(shí)，

寫(xiě)入延遲保證小于兩個(gè)最遠(yuǎn)Azure區(qū)域之間往返時(shí)間(RTT)的兩倍，加上第99個(gè)百分位數(shù)中的10毫秒。

這里有一個(gè)例子。假設(shè)我們創(chuàng)建了一個(gè)Azure CosmosDB賬戶，橫跨Azure新加坡數(shù)據(jù)中心、Azure香港數(shù)據(jù)中心和Azure東京數(shù)據(jù)中心，配置了一個(gè)強(qiáng)一致的場(chǎng)景。

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

因?yàn)樵诜植际较到y(tǒng)中，對(duì)于強(qiáng)寫(xiě)的場(chǎng)景，需要在所有分布式節(jié)點(diǎn)都進(jìn)行了寫(xiě)操作后，才能確定執(zhí)行成功。

此選項(xiàng)當(dāng)前處于預(yù)覽狀態(tài)。

準(zhǔn)確的往返時(shí)間，RTT)取決于光速和Azure網(wǎng)絡(luò)拓?fù)?。Azure network不會(huì)為任何兩個(gè)Azure區(qū)域之間的RTT提供任何延遲SLA。

對(duì)于您的Azure Cosmos帳戶，復(fù)制延遲將顯示在Azure門(mén)戶中。您可以使用Azure portal來(lái)監(jiān)控與您的帳戶相關(guān)聯(lián)的各個(gè)區(qū)域之間的復(fù)制延遲。

一致性級(jí)別和吞吐量

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

對(duì)于給定類(lèi)型的寫(xiě)操作(如插入、替換、更新插入和刪除)，所有一致性級(jí)別在同一請(qǐng)求單元下具有相同的寫(xiě)吞吐量。

一致性扇區(qū)和數(shù)據(jù)持久性

在Azure多區(qū)域分布式數(shù)據(jù)庫(kù)環(huán)境中，當(dāng)發(fā)生區(qū)域服務(wù)中斷時(shí)，一致性級(jí)別與數(shù)據(jù)持久性有直接關(guān)系。在制定業(yè)務(wù)連續(xù)性計(jì)劃時(shí)，有必要知道應(yīng)用程序在中斷事件后完全恢復(fù)之前的最大可接受時(shí)間。完全恢復(fù)一個(gè)應(yīng)用程序所需的時(shí)間稱為恢復(fù)時(shí)間目標(biāo)(RTO)。此外，還需要知道從中斷事件中恢復(fù)時(shí)，應(yīng)用程序可以容忍最新數(shù)據(jù)更新丟失的最長(zhǎng)時(shí)間。您可以承受的更新丟失的時(shí)間限制稱為恢復(fù)點(diǎn)目標(biāo)(RPO)。

下表定義了發(fā)生區(qū)域性服務(wù)中斷時(shí)一致性模型和數(shù)據(jù)持久性之間的關(guān)系。需要注意的是，在分布式系統(tǒng)中，由于CAP定理的存在，即使一致性很高，也不可能存在RPO和RTO為零的分布式數(shù)據(jù)庫(kù)。

K=一個(gè)項(xiàng)目的“k”個(gè)版本(更新)的數(shù)量。

T=時(shí)間“T”，自上次更新以來(lái)的時(shí)間間隔。

特別聲明：以上文章內(nèi)容僅代表作者本人觀點(diǎn)，不代表ESG跨境電商觀點(diǎn)或立場(chǎng)。如有關(guān)于作品內(nèi)容、版權(quán)或其它問(wèn)題請(qǐng)于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。