Azure CosmosDB中的數(shù)據(jù)一致性Azure CosmosDB中的數(shù)據(jù)一致性為了保證分布式數(shù)據(jù)庫的高可用性和低延遲,我們需要在可用性、延遲和吞吐量之間進行權衡。大多數(shù)商業(yè)分布式數(shù)據(jù)庫要求開發(fā)者選擇兩種極端的數(shù)據(jù)庫一致性:強一致性和終極一致性。強一致性是數(shù)據(jù)庫編程的黃金標準。然而,它需要較高的延遲,并且在故障期間......
為了保證分布式數(shù)據(jù)庫的高可用性和低延遲,我們需要在可用性、延遲和吞吐量之間進行權衡。
大多數(shù)商業(yè)分布式數(shù)據(jù)庫要求開發(fā)者選擇兩種極端的數(shù)據(jù)庫一致性:強一致性和終極一致性。
強一致性是數(shù)據(jù)庫編程的黃金標準。然而,它需要較高的延遲,并且在故障期間其可用性較低。
另一方面,最終的一致性提供了更高的可用性和更好的性能,但是應用程序編程非常困難。
Azure Cosmos DB通過一定范圍的選擇實現(xiàn)數(shù)據(jù)一致性,而不是走向兩個極端。
雖然強一致性和最終一致性處于極端,但在整個范圍內有許多一致性選項。開發(fā)人員可以使用這些選項在高可用性或性能方面做出精確的選擇和謹慎的權衡。
使用Azure Cosmos DB,開發(fā)人員可以在一致性范圍內從五個定義良好的一致性模型中進行選擇。
從最強到最弱,這些模型是強的、有界的陳舊性、會話、一致前綴和最終一致性。
該模型定義清晰且直觀。它們可以用于特定的真實場景。每個模型都提供了可用性和性能之間的權衡,并受全面的SLA支持。下圖以范圍間隔的形式顯示了不同的一致性級別。
一致性水平與地區(qū)無關。無論是從哪個區(qū)域提供讀寫,Azure Cosmos帳戶關聯(lián)的區(qū)域數(shù)量,還是帳戶配置單個或多個寫區(qū)域,所有的讀操作都保證Azure Cosmos DB帳戶的一致性級別。
與一致性級別相關的保證
Azure Cosmos DB提供的全面SLA可以保證100%的讀取請求滿足任何選定一致性級別的一致性保證。如果符合與一致性級別相關的所有一致性保證,則讀取請求符合一致性SLA。
下面描述了5個一致性級別的描述:
Strong(強一致性):強一致性保證了讀取操作,并且總是返回最新提交的版本??蛻舳擞肋h不會看到未提交或未完成的寫入。始終確保用戶讀取最新提交的寫入。
有界陳舊性:讀操作(Read)最多可以比寫操作(Write)晚K個版本,即T個時間。如果我們選擇有界陳舊性,陳舊性可以用兩種方式設置:
版本號k
讀操作可能落后于寫操作的時間間隔(t)。
強一致性場景類似于有限過期的概念,但是過期窗口(過期窗口)是0。
當客戶端在接受寫操作的區(qū)域執(zhí)行讀操作時,有界陳舊的一致性提供的保證與強一致性提供的保證相同。
會話:會話一致性的范圍僅限于客戶端會話。
例如,假設我們支持多會話場景。其中一個客戶端A在CosmosDB上進行添加、刪除和查詢操作,所以客戶端只能看到自己提交的內容。
其他客戶B、C等。,看不到客戶端a執(zhí)行操作的結果。
一致前綴:返回的更新包含所有更新的一些前綴,沒有間隔。一致的前綴保證了讀取永遠不會看到無序的寫入。
最終一致性): S2/]不保證閱讀的順序。如果任何進一步的寫入丟失,拷貝將最終收斂。
接下來,我們舉個例子:
讓我們以棒球比賽為例。這場比賽目前在第七局中間。這是第七場比賽。目前客隊25落后。
Azure CosmosDB保存主隊和客隊的分數(shù)。下表列出了五種不同一致性條件下讀取主隊和客隊比分的情況。
有興趣可以參考這篇文章:https://www . Microsoft . com/enus/research/WPcontent/uploads/2011/10/consistencyandbaseballreport . pdf。
特別聲明:以上文章內容僅代表作者本人觀點,不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發(fā)表后的30日內與ESG跨境電商聯(lián)系。
二維碼加載中...
使用微信掃一掃登錄
使用賬號密碼登錄
平臺顧問
微信掃一掃
馬上聯(lián)系在線顧問
小程序
ESG跨境小程序
手機入駐更便捷
返回頂部