iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 3
0

Consistency(一致性), Availability (可用性), Partition Tolerance(分區容忍性) 組成 CAP 定理,在前一文中提到依據不同的狀況下我們必須面臨取捨的問題,藉由了解三者的定義與任取其二所產生出來的效果了解該如何取捨。

CAP

Consistency (一致性)

all nodes see the same data at the same time

在同一時間點任意取兩個節點資料是一致的

Availability (可用性)

Reads and writes always succeed

服務每次都可以在合理的時間內被存取

Partition Tolerance (分區容忍性)

the system continues to operate despite arbitrary message loss or failure of part of the system

在節點間網路連結錯誤或中斷時,不影響整體系統運作

普遍認為最無法被捨去的便是 Partition Tolerance,簡單的說便是確保我們的服務是永遠活著的,即便系統部分節點死亡或無法連接,也可以由其他節點滿足服務需求,在現實的商務活動中這一塊是最需要被確保的。

取捨

我們基於 Partition Tolerance 無法被捨棄的前提下來點單分析一下 CP 與 AP。

  • CP (Consistency & Partition Tolerance) :
    • 效果 : 在犧牲 Availability 的狀況下,將出現任一節點還未更新至最新資料時,進行存取將直接得到失敗錯誤的回應,一直等到全部更新完成才能重新得到正確請求
    • 適用 : 若 Partition 發生,系統依然得以獲取最新的更新的值
  • AP (Availability & Partition Tolerance) :
    • 效果 : 在犧牲 Consistency 的狀況下,任一節點收到的操作都會被執行,並且回應該節點上得到的結果,但不保證最新的值
    • 適用 : 若 Partition 發生,用戶仍然能在正常反應時間內取得結果,而不是直接得到錯誤回應

基於上述效果可以看出

  • AP: 設計適合較不重要的資料(不須永遠都是最新的值,例如在線人數顯示),但又須保證永遠都可以取得(確保你的頁面不會因為小小的在線人數統計死亡或異常)
  • CP: 反之則是需面對一定得取得正確值的狀況(例如針對限量商品的搶購),對於資料正確性至少須保證最終一致性,最終節點須保持相同的結果

以實作面來看待恰似利用 redis(noSQL) 來做快取,mySQL(RDBMS)來做最終資料儲存。


上一篇
Day2 Data consistency
下一篇
Day4 Why Go
系列文
Go Distributed & Go Consistently30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言