在分布式系統中，我們通常增加數據的冗余來達到較高的數據可靠性，多副本和糾刪碼是最常用的兩種數據冗余技術。Quorum 機制則是經常配合冗余副本管理的一種機制。

我們先考慮一個簡單的場景，你的系統是 3 副本設計，怎么讀寫流程比較好？直觀來講，寫的時候 3 副本都寫成功才報告成功，那么讀的時候隨便讀哪個副本都是可以的。這個是最簡單的副本策略：write-all-read-one，簡稱 WARO，也是最常用的一種副本策略。

Write-all-read-one

對于多副本冗余的系統來說，寫的時候，所有的副本節點寫都成功才算成功（write all），讀的時候就可以隨便讀一個副本即可（read one）。這個就很容易理解，因為有這么個假設存在：只要寫成功了，那么多副本的數據就是一致的，你隨便讀哪個都是正確的數據（不考慮靜默或其他問題，靜默導致的問題用數據自校驗解決）。

現在我們想一個問題，為什么 WARO 的模式下，在讀的時候可以隨便讀任一副本的數據？

關鍵在于：我們讀的是寫成功的數據，這個是 Write-All 這個前提保證的。現在思考下優缺點：

優點：

• 實現簡單，無需考慮復雜的異常處理，讀的時候高效；

缺點：

• 寫的可用性不大好，由于更新寫操作需要在所有的 N 個副本都成功，寫操作才算成功，所以一旦有一個副本異常，寫失敗，則更新操作不可用。對于更新服務來說，雖然系統有 N 個副本，但系統卻無法容忍任何一個副本異常；
• 讀的可用性挺好的，N 個副本中，只要有一個副本正常提供服務，系統就可以提供讀服務，換句話說，系統可以容忍 N-1 個副本異常；

所以，我們看到 WARO 讀寫可用性的區別，更新服務的可用性太低了，系統雖然使用了多副本，但是更新操作的可用性等效于沒有副本。

能優化這個嗎？可以的，其實就是 CAP 理論，WARO 保證了數據的高度一致性，但是犧牲了寫更新的可用性，我們的優化思路就是把可用性適當上調，自然數據的一致性就會下調，Quorum 就是提高寫更新可用性的一種機制。

Quorum

Quorum 定義

WARO 犧牲寫更新的可用性，帶來了系統的簡潔性，也是讀的可用性達到了副本機制的最高狀態。我們把 WARO 條件放寬，不要求 Write-all，從而使得讀寫服務的可用性之間做個折中，這個就是 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] 更新后的數據 vi。原理圖示：

仔細體會下上面的描述，這個推演是這么來的：

1. 由于 WARO 模式下更新操作條件太嚴苛，我們想提高更新操作的可用性，于是適當放寬，允許更新操作的時候 N 個中有失敗的，成功 W 個也沒關系，照樣返回成功，這樣寫的可用性就上來了；
1. 雖然數據可靠性短時間的內會處于一個不完整的狀態，但是帶來的是可用性的提升；
2. 由于引入 Quorum 機制后，更新操作成功的時候，N 個副本不一定都是最新成功的數據，所以我們讀的時候就不能自由的讀任意副本，而是一定要讀到成功的數據才行，于是才有了每次讀都要讀 R 個副本，并且 R+W 要滿足 > N 才行，因為這樣才能保證你讀到的 R 個副本里一定有包含正確的數據；
1. 保證了 R+W > N 這個條件，才能保證讀的副本集合和寫的副本集合有交集；

舉例子，系統是 5 副本的，令 W=3，R=3，最初 5 個副本數據都一致，都是 v1，某次更新操作 w2 再前 3個副本成功，副本情況變成（v2 v2 v2 v1 v1）。此時，任意 3 個副本組成的集合中一定包含 v2。

其實，上述定義中，令 W=N，R=1，其實就等價 WARO，所以這么來講，WARO 是 Quorum 機制的一種特例。

思考一個問題：你讀 R 個副本數據上來，雖然一定包含了正確的數據，但是你怎么甄別出來正確的數據？記得不要代入你的上帝視角哈。

針對這個問題，我們有個很重要的結論：只依賴 quorum 機制是無法保證數據的強一致性的。因為就算你讀到了正確的數據，假如沒有其他手段輔助的話，你也是無法甄別出正確的數據的。

舉個例子：

1. 5 副本的系統，令 W = 3，R=3，初始化值都是 v1，則為 [v1, v1, v1, v1, v1 ]
2. 一次寫更新之后，系統狀態變成 [v2, v2, v2, v1, v1]
3. 由于 R=3，根據 qurom 的規則，我們只需要讀到 3 份副本數據，就能讀到正確的值。窮舉下，那么 R =3 ，讀到的副本列表有三種情況：
• [v2, v2, v1]
• [v2, v2, v2]
• [v2, v1, v1]

我們看到 無論哪種，v2 都在列表里，我們站在上帝視角，自然知道這個就是正確的數據。但是對于這三種場景，你需要怎么處理才能確保每次都識別出正確的數據是 v2 呢？

其實只有第二種情況 [v2, v2, v2]，你才能斷定 v2 是正確的，因為列表里只有 v2。

第一種情況 [v2, v2, v1] 和 第三種情況 [v2, v1, v1] 你都還需要其他進一步的手段，你才能識別出正確的數據。比如第一種情況 [ v2, v2, v1 ] 你會取哪個值作為正確的值？v2？因為 v2 是多數？但是第三種情況下 v1 還是多數呢。

這種情況需要進行一些額外的操作來確認正確的副本，而且最終可能還無法區分。

如何確定最新遞交的值？

Quorum 機制說明，只需要成功更新 N 個副本中的 W 個，在讀取 R 個副本時，滿足 W+R > N 的條件時，一定可以讀到最新的成功的數據。但由于有更新失敗的情況存在，僅僅讀到 R 個副本卻不一定能確定哪個是正確的數據。

還是以這個舉例：假定 N=5，W=3，R=3 的系統，初始化為 [v1, v1, v1, v1, v1]，成功一次更新之后，某時刻狀態為 [v2, v2, v2, v1, v1] ，也就是前三個副本更新成功，由于 W=3，滿足條件，那么本次算成功的更新。

這個時候，讀取任何 3 個副本，一定能讀到 v2，情況也不多，只有三種情況，我們窮舉下：

• [v2, v2, v2]
• [v2, v2, v1]
• [v2, v1, v1]

我們無法判斷究竟是 v1，還是v2是最新的成功遞交的數據？

我們可以頭腦風暴下；

方法一，每次寫副本成功，再寫一份元數據記錄本次請求，比如把成功的版本 v2 記錄下來，這樣你就有辦法知道數據正確的是哪個版本了。

方法二，或者，我們對讀取條件做進一步加強：

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

所以我們再思考下，這三種情況：

• [v2, v2, v2]
• 3 個副本都是 v2 ，v2版本的個數 >=3，那么 v2 就是最新成功的版本
• [v2, v2, v1]
• [v2, v2, v1, v1] ：這種情況還需要繼續讀，因為v2, v1的個數都還不滿足 >= 3；
• [v2, v2, v2, v1] ：v2的個數 >=3 ，所以斷定 v2 是最新成功遞交的數據；
• [v2, v2, v2, v1, v1] ：這個時候，終于可以斷定，v2 就是成功遞交的那個最新數據
• 兩個數據是 v2，一個是 v1，那么還需要繼續讀，有兩種情況：
• [v2, v1, v1]
• 這個情況類似，也是繼續讀，知道某個數據版本個數滿足條件 >= 3

如果這個繼續讀的過程失敗，或者超時了，那么就無法判斷了。