今天繼續介紹 CAP Theorem

Availability

即系統能夠持續提供服務的能力

如上篇所說, 強一致性 的設計可以確保跨節點資料的一致性, 但是等待同步的時間較長, 造成我們的服務在同步結束前無法回應, 這就犧牲了 Availability

最終一致性 的設計則可以 提升 Availability, 但會造成一段時間內的資料 不一致

這裡只是 設計間的比較, 實際上的效能差異不一定顯著

Partition Tolerance

即系統 容忍分區錯誤 (即 ISP 問題, 網路線壞掉, DNS, router 錯誤等等) 發生的程度

以上篇的訂房系統為例, 當 分區錯誤 (即 ISP 問題, 網路線壞掉, DNS, router 錯誤等等) 發生, 我們的服務彼此就無法溝通

先用是否 容忍分區錯誤 來說明

容忍分區錯誤

如果設計上選擇 容忍分區錯誤, 則即使發生 分區錯誤, 使用者仍然能夠使用我們的系統訂房

達成方法可以分為

• Redundancy (冗餘)
• Replica (複製)

Reduncancy

我們可以在系統中 擴展更多設備或服務, 比如更多節點或網路設備, 和 RAID 備份的概念有點像, 當一個設備壞掉, 我們就用其他設備支援

Replica

Replica 也算是 Redundancy 的一種, 但主要是為了提升可用性; Redundancy 則是為了容忍分區錯誤

我們可以將每個節點都複製多份, 當節點下線或錯誤時, 我們就可以用 複製節點 來回應請求, 提升系統的可用性

High Availability

高可用性 (High Availability) 可以作為系統可用性的設計標準, 比如 AWS 的 High availability and scalability on AWS 介紹
雲端服務通常會提供 Service Level Agreement (SLA, 服務等級協議) 協議服務可用性的等級, 常見的等級有

• 99.9% (3 Nines)
  一年內最多允許 8.76 小時的停機時間
• 99.99% (4 Nines)
  一年內最多允許 52.56 分鐘的停機時間
• 99.999% (5 Nines)
  一年內最多允許 5.26 分鐘的停機時間
• 99.9999% (6 Nines)
  一年內最多允許 31.5 秒的停機時間

SLA 還有定義其他如 性能指標 等等

• 響應時間：
  95% 的請求在 100 ms 內得到回應
• 處理時間：
  99% 的交易在 1 秒內完成
• 吞吐量：
  每秒處理至少 1000 個請求

有興趣請自行查閱~

Consistency, Availability, Partition Tolerance 選二

所以為什麼只能三選二呢?

CP 系統

當 分區錯誤 發生, 由於某些節點無法接收請求, 造成節點狀態不一致

若我們選擇 "一致性", 我們就需要 "阻擋使用者請求" 直到 同步完成
這就犧牲了 可用性

AP 系統

同上面的情境, 當 分區錯誤 發生, 若我們選擇 "可用性", 則使用者可以繼續使用服務, 但由於節點狀態尚未同步完成, 使用者會拿到舊的資料
這就犧牲了 "一致性"

CA 系統

即不存在 分區錯誤 時, 我們可以保證 一致性 和 可用性 (相對於分區錯誤存在時)

實務上不存在這種分散式系統, 因為 分區錯誤 是客觀存在且會發生的, 所以我們需要在 CP 和 AP 系統中選擇

Reference

• Choose a RAID Type
• High availability and scalability on AWS
• AWS Service Level Agreements (SLAs)