分布式系統原理

Quorum 機制

Quorum 機制是一種簡單有效的副本管理機制。本節首先討論一種最簡單的副本控制規則write-all-read-one，在此基礎上，放松約束，討論 quorum 機制。

1. 約定

為了簡化討論，本節先做這樣的約定：更新操作（write）是一系列順序的過程，通過其他機制確定更新操作的順序（例如 primary-secondary 架構中由 primary 決定順序），每個更新操作記為 w i ，i 為更新操作單調遞增的序號，每個 w i 執行成功后副本數據都發生變化，稱為不同的數據版本，記作 v i 。假設每個副本都保存了歷史上所有版本的數據。

2. Write-all-read-one

Write-all-read-one（簡稱 WARO）是一種最簡單的副本控制規則，顧名思義即在更新時寫所有的副本，只有在所有的副本上更新成功，才認為更新成功，從而保證所有的副本一致，這樣在讀取數據時可以讀任一副本上的數據。

• 假設有一種 magic 的機制，當某次更新操作 w i 一旦在所有 N 個副本上都成功，此時全局都能知道這個信息，此后讀取操作將指定讀取數據版本為 v i 的數據，稱在所有 N 個副本上都成功的更新操作為“成功提交的更新操作”，稱對應的數據為“成功提交的數據”。在 WARO 中，如果某次更新操作 w i 在某個副本上失敗，此時該副本的最新的數據只有 v i-1 ，由于不滿足在所有 N 個副本上都成功，則 w i 不是一個“成功提交的更新操作”，此時，雖然其他 N-1 個副本上最新的數據是 v i ，但 v i 不是一個“成功提交的數據”，最新的成功提交的數據只是 v i-1 。

• 分析一下 WARO 的可用性。由于更新操作需要在所有的 N 個副本上都成功，更新操作才能成功，所以一旦有一個副本異常，更新操作失敗，更新服務不可用。對于更新服務，雖然有 N 個副本，但系統無法容忍任何一個副本異常。另一方面，N 個副本中只要有一個副本正常，系統就可以提供讀服務。對于讀服務而言，當有 N 個副本時，系統可以容忍 N-1 個副本異常。

• 從上述分析可以發現 WARO 讀服務的可用性較高，但更新服務的可用性不高，甚至雖然使用了副本，但更新服務的可用性等效于沒有副本。

• WARO 犧牲了更新服務的可用性，最大程度的增強讀服務的可用性。

3. Quorum 定義

在 Quorum 機制下，當某次更新操作 w i 一旦在所有 N 個副本中的 W 個副本上都成功，則就稱該更新操作為“成功提交的更新操作”，稱對應的數據為“成功提交的數據”。令 R>N-W，由于更新操作 w i 僅在 W 個副本上成功，所以在讀取數據時，最多需要讀取 R 個副本則一定能讀到 w i 更新后的數據 v i 。如果某次更新 w i 在 W 個副本上成功，由于 W+R>N，任意 R 個副本組成的集合一定與成功的 W 個副本組成的集合有交集，所以讀取 R 個副本一定能讀到 w i 更新后的數據 v i 。

例 2.4.1，某系統有 5 個副本，W=3，R=3，最初 5 個副本的數據一致，都是 v 1 ， 某次更新操作w 2 在前 3 副本上成功，副本情況變成（v 2 v 2 v 2 v 1 v 1 ）。此時，任意 3 個副本組成的集合中一定包括v 2 。

在上述定義中，令 W=N，R=1，就得到 WARO，即 WARO 是 Quorum 機制的一種特例。

與分析 WARO 相似，分析 Quorum 機制的可用性。限制 Quorum 參數為 W+R=N+1。由于更新操作需要在 W 個副本上都成功，更新操作才能成功，所以一旦 N-W+1 個副本異常，更新操作始終無法在 W 個副本上成功，更新服務不可用。另一方面，一旦 N-R+1 個副本異常，則無法保證一定可以讀到與 W 個副本有交集的副本集合，則讀服務的一致性下降。

Quorum 機制的三個系統參數 N、W、R 控制了系統的可用性，也是系統對用戶的服務承諾：數據最多有 N 個副本，但數據更新成功 W 個副本即返回用戶成功。

4. 讀取最新成功提交的數據

上節中，假設有某種 magic 的機制使得讀取者知道當前已提交的數據版本號。本節取消這種假設，分析在 Quorum 機制下，如何始終讀取成功提交的數據，以及如何確定最新的已提交的數據。

Quorum 機制只需成功更新 N 個副本中的 W 個，在讀取 R 個副本時，一定可以讀到最新的成功提交的數據。但由于有不成功的更新情況存在，僅僅讀取 R 個副本卻不一定能確定哪個版本的數據是最新的已提交的數據。
例 2.4.3，在 N=5，W=3，R=3 的系統中，某時刻副本最大版本號為 （ v 2 v 2 v 2 v 1 v 1 ）。注意，這里繼續假設有 v 2 的副本也有 v 1 ，上述列出的只是最大版本號。此時，最新的成功提交的副本應該是 v 2 ，因為從全局看 v 2 已經成功更新了 3 個副本。讀取任何 3 個副本，一定能讀到 v 2 。 但僅讀 3 個副本時，有可能讀到 （ v 2 v 1 v 1 ），如圖 2-11（a）。此時，由于 v 2 蘊含 v 1 ， 可知 v 1 是一個成功提交的版本 ， 但卻不能判定 v 2 一定是一個成功提交的版本 。 這是因為，圖 2-11（b）,假設副本最大版本號為 （ v 2 v 1 v 1 v 1 v 1 ），當讀取 3 個副本時也可能讀到 （ v 2 v 1 v 1 ）,此時 v 2 是一個未成功提交的版本。所以在本例中，僅僅讀到 （ v 2 v 1 v 1 ）時，可以肯定的是最新的成功提交的數據要么是 v 1 要么是 v 2 ，卻沒辦法確定究竟是哪一個 。

對于一個強一致性系統，應該始終讀取返回最新的成功提交的數據，在 quorum 機制下，要達到這一目的需要對讀取條件做進一步加強。

1. 限制提交的更新操作必須嚴格遞增，即只有在前一個更新操作成功提交后才可以提交后一個更新操作，從而成功提交的數據版本號必須是連續增加的。 2. 讀取 R 個副本，對于 R 個副本中版本號最高的數據， 2.1 若已存在 W 個，則該數據為最新的成功提交的數據 2.2 若存在個數據少于 W 個，假設為 X 個，則繼續讀取其他副本，直若成功讀取到 W 個該版本的副本，則該數據為最新的成功提交的數據；如果在所有副本中該數據的個數肯定不滿足 W 個，則 R 中版本號第二大的為最新的成功提交的副本。

例 2.4.4：依舊接例 2.4.3，在讀取到 （ v 2 v 1 v 1 ）時，繼續讀取剩余的副本，若讀到剩余兩個副本為（v 2 v 2 ）則 v 2 是最新的已提交的副本；若讀到剩余的兩個副本為（v 2 v 1 ）或（v 1 v 1 ）則 v 1 是最新成功提交的版本；若讀取后續兩個副本有任一超時或失敗，則無法判斷哪個版本是最新的成功提交的版本。

可以看出，在單純使用 Quorum 機制時，若要確定最新的成功提交的版本，最多需要讀取 R+（W-R-1）=N 個副本，當出現任一副本異常時，讀最新的成功提交的版本這一功能都有可能不可用。實際工程中，應該盡量通過其他技術手段，回避通過 Quorum 機制讀取最新的成功提交的版本。例如，當 quorum 機制與 primary-secondary 控制協議結合使用時，可以通過讀取 primary 的方式讀取到最新的已提交的數據。

5. 基于 Quorum 機制選擇 primary

本節介紹一種介于 quorum 機制選擇 primary 的技術。回憶 2.2.2 節，基本 primary-secondary 協議中，primary 負責進行更新操作的同步工作。現在基本 primary-secondary 協議中引入 quorum 機制，即 primary 成功更新 W 個副本(含 primary 本身)后向用戶返回成功。

在 primary-secondary 協議中，當 primary 異常時，需要選擇出一個新的 primary，之后 secondary 副本與 primary 同步數據。通常情況下，選擇新的 primary 的工作是由某一中心節點完成的，在引入 quorum 機制后，常用的 primary 選擇方式與讀取數據的方式類似，即中心節點讀取 R 個副本，選擇 R 個副本中版本號最高的副本作為新的 primary。新 primary 與至少 W 個副本完成數據同步后作為新 的 primary 提供讀寫服務。首先，R 個副本中版本號最高的副本一定蘊含了最新的成功提交的數據。 再者，雖然不能確定最高版本號的數是一個成功提交的數據，但新的 primary 在隨后與 secondary 同步數據，使得該版本的副本個數達到 W，從而使得該版本的數據成為成功提交的數據。

例 2.4.5：在 N=5，W=3，R=3 的系統中，某時刻副本最大版本號為 （ v 2 v 2 v 1 v 1 v 1 ），此時 v 1 是系統的最新的成功提交的數據 ， v 2 是一個處于中間狀態的未成功提交的數據。假設此刻原 primary副本異常，中心節點進行 primary 切換工作。這類“中間態”數據究竟作為“臟數據”被刪除，還是作為新的數據被同步后成為生效的數據，完全取決于這個數據能否參與新 primary 的選舉。下面分別分析這兩種情況。

• 第一、如圖 2-12，若中心節點與其中 3 個副本通信成功，讀取到的版本號為（v 1 v 1 v 1 ），則任選一個副本作為primary，新primary以v 1 作為最新的成功提交的版本并與其他副本同步，當與第1、第 2 個副本同步數據時，由于第 1、第 2 個副本版本號大于 primary，屬于臟數據，可以按照 2.2.2.4節中介紹的處理臟數據的方式解決。實踐中，新 primary 也有可能與后兩個副本完成同步后就提供數據服務，隨后自身版本號也更新到 v 2 ， 如果系統不能保證之后的 v 2 與之前的 v 2 完全一樣，則新primary 在與第 1、2 個副本同步數據時不但要比較數據版本號還需要比較更新操作的具體內容是否一樣。

第二、若中心節點與其他 3 個副本通信成功，讀取到的版本號為（v 2 v 1 v 1 ），則選取版本號為v2 的副本作為新的 primary，之后，一旦新 primary 與其他 2 個副本完成數據同步，則符合 v 2 的副本個數達到 W 個，成為最新的成功提交的副本，新 primary 可以提供正常的讀寫服務。

6. 工程投影

• GFS 中的 Quorum。GFS 使用 WARO 機制讀寫副本。GFS 系統不保證異常狀態時副本的一致性，GFS 系統需要上層應用通過 Checksum 等機制自行判斷數據是否合法。

• Dynamo 中的 Quorum。Dynamo/Cassandra 是一種去中心化的分布式存儲系統。Dynamo 使用 Quorum 機制來管理副本。用戶可以配置 N、R、W 的參數，并保證滿足 R+W>N 的 quorum 要求。Dynamo 提出了一種 clock vector 的方法，該方法的思路就是記錄數據的版本變化，以類似 MVCC（2.7 ）的方式幫助用戶解決數據沖突。所謂 clock vector即記錄了數據變化的路徑的向量，為每個更新操作維護分配一個向量元素，記錄數據的版本號及主導該次更新的副本名字。

• Zookeeper 中的 Quorum。Zookeeper 使用的 paxos 協議本身就是利用了 Quorum機制，在 2.8 中有詳細分析，這里不贅述。當利用 paxos 協議外選出 primary 后，Zookeeper 的更新流量由 primary 節點控制，每次更新操作，primary 節點只需更新超過半數（含自身）的節點后就返回用戶成功。每次更新操作都會遞增各個節點的版本號（xzid）。當 primary 節點異常，利用 paxos 協議選舉新的 primary 時，每個節點都會以自己的版本號發起 paxos 提議，從而保證了選出的新 primary 是某個超過半數副本集合中版本號最大的副本。

• Mola*/Armor*中的 Quorum。Mola*和 Armor*系統中所有的副本管理都是基于 Quorum，即數據在多數副本上更新成功則認為成功。

• Big Pipe*中的 Quorum。Big Pipe*中的副本管理也是采用了 WARO 機制。

參考：《分布式系統原理介紹》 - 劉杰

總結

以上是生活随笔為你收集整理的分布式系统原理 之4 Quorum 机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。