Eventually Consistent 與 Dynamo NWR 模型


整理 AWS CTO - Werner Vogels 著名的論文: Eventually Consistent (ACM), (Blog) 重點與筆記。


相關名詞

  • Client side consistency: 客戶端一致性
    • Strong consistency:強一致性
    • Weak consistency:弱一致性
    • Eventually consistency:最終一致性
  • Server side consistency: 簡稱 NWR 模型,目的是 CAP 選擇權的反轉
    • N 代表 N 個複本 (Replica)
    • W 寫入至少 W 個複本才算成功
    • R 至少讀取 R 個備份
    • R 與 W 的選擇,必須是 W + R > N,否則無法保證一致性

Client side consistency

Client Side 有四種元件:

  • A storage system: 儲存單位,假設是個黑盒子。
  • Process A: 從 storage 讀寫資料
  • Process B & C: 獨立於 Process A 的程序,同樣從 storage 讀寫資料。

用戶端的一致性必須讓觀察者 (Obsever, Process A/B/C) 知道 如何何時 針對 Stroage 更新物件資料。底下是的例子是 Process A 更新到物件:

  • Strong consistency:強一致性,更新完成之後,任何存取的子程序 (subsequenet access) 都會回傳更新得值
  • Weak consistency:弱一致性,系統不保證子程序會取得最新的值。有些必要的條件必須被滿足後,才會回傳更新值。條件通常跟經過多少時間 (passing of time) 有關係
  • Eventually consistency:最終一致性,系統會保證最後會取得最後更新得值,最常見的案例就是 DNS 系統。

針對 最終一致性模型,底下是必要的考量:

  • Causal consistency (因果一致性):
  • Read-your-writes consistency (讀已經寫的一致性)
  • Session consistency (階段一致性)
  • Monotonic read consistency (單調讀取一致性)
  • Monotonic write consistency (單調寫入一致性)

Server side consistency

開始描述之前,定義以下名詞:

  • N: 代表 N 個複本 (Replica),資料被複製到多少實體主機,通常這個值至少是 3
  • R: 代表一次成功的讀取操作中,最小的結點數,也就是要讀取多少個 Replica 才算是讀取成功。
  • W: 寫入至少 W 個複本才算成功

R 與 W 的選擇,這代表著:

  • W + R <= N,讀 (W) 與寫 (R) 的數量 <= 複本數 (N):複本數剛好可以分配到所有請求,不會有讀寫一致性問題
  • W + R > N,讀 (W) 與寫 (R) 的數量 > 複本數 (N):複本數少於讀寫請求數量,必須處理一致性問題,也就是無法保證一致性。

此概念稱為 NRW 模型、或者 NWR 模型


NWR 與 CAP 的選擇

CAP 倆倆相對,與 NWR 的關係與應用場景。

AP (Available and Partition tolerance)

可用性與分區容錯,亦即 寫多、讀少

需要寫多讀少,也就是 優化寫入效能,會配置 W = 1,也就是寫入一個複本就算是成功,就如同單機的 RDBMS,其他非同步的複本可以慢慢抄寫。

CP (Consistency and Partition tolerance)

資料一致性與分區容錯,亦即 讀多、寫少

需要讀取比較多,也就是 優化讀取效能,通常會配置 W = N

AC (Availability and Consistency)

可用性與資料一致性,亦即 讀寫平衡

不需要容錯和擴展性的時候,配置一個複本: N = 1

把 CAP 交給用戶決定

NWR 模型的概念,就是把選擇權交給用戶決定,讓用戶自己決定選擇 CAP 中的哪兩個。

解釋

最終一致性到底要怎麼解釋呢?底下是網友用漫畫的解釋,很有趣 XD

lol what a great definition of 'eventual consistency'
Source: Greg Young


延伸閱讀

站內延伸

參考資料


Comments