本章涵蓋四種分散式系統中的一致性與容錯模式:法定人數(Quorum)領導者與追隨者(Leader and Follower)CAP 定理(CAP Theorem) 以及 PACELC 定理(PACELC Theorem)


法定人數(Quorum)#

背景#

在分散式系統(Distributed Systems)中,資料會被複製到多台伺服器上,以實現容錯(Fault Tolerance)與高可用性(High Availability)。一旦系統決定維護多份資料副本,便會產生另一個問題:如何確保所有副本都是一致的?亦即,它們是否都擁有最新的資料,且所有客戶端看到的資料視圖是否相同?

定義#

在分散式環境中,法定人數(Quorum)是指一項分散式操作在宣告整體成功之前,需要在最少多少台伺服器上成功執行的數量。

解決方案#

假設資料庫被複製到五台機器上,則三台機器構成多數法定人數(Majority Quorum)。如果這三台機器達成一致,我們便提交該操作。法定人數強制執行了分散式操作所需的一致性要求。

在擁有多個副本的系統中,使用者有可能讀取到不一致的資料。例如,當叢集中有三個副本 R1、R2 和 R3 時,使用者將值 v1 寫入副本 R1,然後另一個使用者從仍落後於 R1 的副本 R2 或 R3 讀取,此時第二個使用者將無法獲得值 v1,也就無法看到一致的資料狀態。

法定人數的值應該選擇多少?應超過叢集中節點總數的一半:(N/2 + 1),其中 N 為叢集中的節點總數。例如:

  • 5 節點叢集中,至少三個節點必須在線才能構成多數
  • 4 節點叢集中,至少三個節點必須在線才能構成多數
  • 5 節點叢集可以承受兩個節點故障,而 4 節點叢集只能承受一個節點故障

基於上述邏輯,建議叢集中的節點總數始終為奇數,以最大化容錯能力。

法定人數透過以下協定實現:R + W > N,其中:

  • N = 法定人數群組中的節點數
  • W = 最少寫入節點數
  • R = 最少讀取節點數

若分散式系統遵循 R + W > N 規則,則每次讀取都能至少看到一份最新寫入的資料副本。以下是幾種常見配置:

  1. (N=3, W=2, R=2) — 確保強一致性(Strong Consistency)
  2. (N=3, W=1, R=3) — 寫入快、讀取慢,耐久性較低
  3. (N=3, W=3, R=1) — 寫入慢、讀取快,耐久性高

R=1, W=N 代表完全複製(Write-All, Read-One)策略。當伺服器可能不可用時,這種配置並不理想,因為寫入操作無法保證完成。

實際應用#

  • Chubby:使用 Paxos 進行領導者選舉,Paxos 利用法定人數來確保強一致性
  • Cassandra:每個寫入請求可配置為僅在資料成功寫入至少法定人數(即多數)的副本節點後,才視為成功
  • Dynamo:將寫入複製到系統中其他節點的寬鬆法定人數(Sloppy Quorum),而非像 Paxos 那樣的嚴格多數法定人數。所有讀寫操作都在偏好列表(Preference List)中前 N 個健康節點上執行,這些節點可能並非一致性雜湊環上遇到的前 N 個節點

領導者與追隨者(Leader and Follower)#

背景#

分散式系統使用法定人數(Quorum)來確保副本之間的資料一致性,但法定人數可能導致較低的可用性——系統在任何時候都需要確保至少多數副本處於可用狀態,否則操作將失敗。此外,在某些故障情境下,法定人數也不足以保證客戶端看到一致的資料。

定義#

僅允許單一伺服器(稱為領導者,Leader)負責資料複製與工作協調。

解決方案#

在此模式中,一台伺服器被選舉為領導者(Leader),負責所有的資料複製與協調工作:

  • 追隨者(Follower)接受來自領導者的寫入操作,並作為備份
  • 若領導者發生故障,其中一個追隨者會被提升為新的領導者
  • 追隨者可以為讀取請求提供服務,以實現負載平衡

領導者與追隨者模式透過將寫入集中到單一節點來簡化一致性管理,但也引入了單點故障(Single Point of Failure)的風險,因此需要可靠的領導者選舉機制來配合。

實際應用#

  • Kafka:每個分區(Partition)都有一個指定的領導者,負責該分區的所有讀寫操作。控制器代理(Controller Broker)負責管理性操作
  • Chubby:在啟動時使用 Paxos 演算法執行領導者選舉,確保只有一個節點作為領導者進行協調

CAP 定理(CAP Theorem)#

背景#

在分散式系統中,可能發生各種不同的故障,包括伺服器崩潰、磁碟故障、網路連線中斷等。系統應如何建構自身模型,以在這些故障情境下獲得最大效益?

定義#

CAP 定理指出,分散式系統不可能同時提供以下三項保證:

  • 一致性(Consistency, C):所有節點在同一時間看到相同的資料
  • 可用性(Availability, A):每個對未故障節點的請求都必須得到回應
  • 分區容錯性(Partition Tolerance, P):即使部分節點故障或訊息遺失,系統仍能繼續運作

解決方案#

系統必須在三者中選擇兩項,理論上有三種組合:

組合包含犧牲
CA一致性 + 可用性分區容錯性
CP一致性 + 分區容錯性可用性
AP可用性 + 分區容錯性一致性

在實際的分散式系統中,網路分區是不可避免的。因此 CA 組合在實務上並不合理——當分區發生時,系統必然會失去一致性或可用性。真正的選擇是:在網路分區存在的情況下,選擇一致性(C)還是可用性(A)

實際應用#

  • Dynamo:屬於 AP 系統,以犧牲強一致性為代價換取高可用性
  • BigTable:屬於 CP 系統,提供嚴格一致的讀寫操作

PACELC 定理(PACELC Theorem)#

背景#

CAP 定理告訴我們在網路分區發生時需要在一致性與可用性之間做出選擇。但是,當沒有網路分區時會怎樣?傳統的 ACID 資料庫選擇了一致性,而 BASE 資料庫選擇了可用性。PACELC 定理擴展了 CAP 定理,涵蓋了無分區情境下的取捨。

定義#

PACELC 定理的含義為:

  • 若發生分區(Partition, P),則在**可用性(Availability, A)一致性(Consistency, C)**之間取捨
  • 否則(Else, E),在**延遲(Latency, L)一致性(Consistency, C)**之間取捨

解決方案#

PACELC 定理由兩部分組成:

  • PAC 部分與 CAP 定理相同,描述分區發生時的取捨
  • ELC 部分是擴展,描述正常運作(無分區)時的取捨

此定理假設透過複製(Replication)實現高可用性。在故障期間,CAP 定理的取捨生效;在正常運作期間,系統需要在一致性延遲之間做出取捨。

PACELC 定理比 CAP 定理更能全面描述分散式系統的設計取捨,因為它同時考慮了故障情境與正常運作情境。

實際應用#

系統分類分區時選擇正常運作時選擇
Dynamo / CassandraPA/EL可用性低延遲
BigTable / HBasePC/EC一致性一致性
MongoDBPA/EC可用性一致性