分佈式系統理論之Quorum機制

一，Quorum機制介紹

在分佈式系統中有個CAP理論，對於P（分區容忍性）而言，是實際存在 從而沒法避免的。由於，分佈系統中的處理不是在本機，而是網絡中的許多機器相互通訊，故網絡分區、網絡通訊故障問題沒法避免。所以，只能儘可能地在C 和 A 之間尋求平衡。對於數據存儲而言，爲了提升可用性（Availability），採用了副本備份，好比對於HDFS，默認每塊數據存三份。某數據塊所在的機器宕機了，就去該數據塊副本所在的機器上讀取（從這能夠看出，數據分佈方式是按「數據塊」爲單位分佈的）

可是，問題來了，當須要修改數據時，就須要更新全部的副本數據，這樣才能保證數據的一致性（Consistency）。所以，就須要在 C(Consistency) 和 A(Availability) 之間權衡。

而Quorum機制，就是這樣的一種權衡機制，一種將「讀寫轉化」的模型。在介紹Quorum以前，先看一個極端的狀況：WARO機制

 WARO(Write All Read one)是一種簡單的副本控制協議，當Client請求向某副本寫數據時(更新數據)，只有當全部的副本都更新成功以後，此次寫操做纔算成功，不然視爲失敗。

從這裏能夠看出兩點：①寫操做很脆弱，由於只要有一個副本更新失敗，這次寫操做就視爲失敗了。②讀操做很簡單，由於，全部的副本更新成功，才視爲更新成功，從而保證全部的副本一致。這樣，只須要讀任何一個副本上的數據便可。假設有N個副本，N-1個都宕機了，剩下的那個副本仍能提供讀服務；可是隻要有一個副本宕機了，寫服務就不會成功。

 

 WARO犧牲了更新服務的可用性，最大程度地加強了讀服務的可用性。而Quorum就是更新服務和讀服務之間進行一個折衷。

Quorum機制是「抽屜原理」的一個應用。定義以下：假設有N個副本，更新操做w_i 在W個副本中更新成功以後，才認爲這次更新操做w_i 成功。稱成功提交的更新操做對應的數據爲：「成功提交的數據」。對於讀操做而言，至少須要讀R個副本才能讀到這次更新的數據。其中，W+R>N ，即W和R有重疊。通常，W+R=N+1

假設系統中有5個副本，W=3，R=3。初始時數據爲(V₁，V₁，V₁，V₁，V₁）--成功提交的版本號爲1

當某次更新操做在3個副本上成功後，就認爲這次更新操做成功。數據變成：(V₂，V₂，V₂，V₁，V₁）--成功提交後，版本號變成2

所以，最多隻須要讀3個副本，必定可以讀到V₂(這次更新成功的數據)。而在後臺，可對剩餘的V₁ 同步到V₂，而不須要讓Client知道。

 

二，Quorum機制分析

①Quorum機制沒法保證強一致性

所謂強一致性就是：任什麼時候刻任何用戶或節點均可以讀到最近一次成功提交的副本數據。強一致性是程度最高的一致性要求，也是實踐中最難以實現的一致性。

 由於，僅僅經過Quorum機制沒法肯定最新已經成功提交的版本號。

好比，上面的V₂ 成功提交後（已經寫入W=3份），儘管讀取3個副本時必定能讀到V₂，若是恰好讀到的是(V₂，V₂，V₂），則這次讀取的數據是最新成功提交的數據，由於W=3，而此時恰好讀到了3份V₂。若是讀到的是（V₂，V₁，V₁），則沒法肯定是一個成功提交的版本，還須要繼續再讀，直到讀到V₂的達到3份爲止，這時才能肯定V₂ 就是已經成功提交的最新的數據。

1）如何讀取最新的數據？---在已經知道最近成功提交的數據版本號的前提下，最多讀R個副本就能夠讀到最新的數據了。

2）如何肯定 最高版本號 的數據是一個成功提交的數據？---繼續讀其餘的副本，直到讀到的 最高版本號副本 出現了W次。

 

②基於Quorum機制選擇 primary

中心節點(服務器)讀取R個副本，選擇R個副本中版本號最高的副本做爲新的primary。

新選出的primary不能當即提供服務，還須要與至少與W個副本完成同步後，才能提供服務---爲了保證Quorum機制的規則：W+R>N

至於如何處理同步過程當中衝突的數據，則須要視狀況而定。

 好比，(V₂，V₂，V₁，V₁，V₁），R=3，若是讀取的3個副本是：(V₁，V₁，V₁)則高版本的 V₂須要丟棄。

若是讀取的3個副本是（V₂，V₁，V₁），則低版本的V₁須要同步到V₂

 

三，Quorum機制應用實例

HDFS高可用性實現

 HDFS的運行依賴於NameNode，若是NameNode掛了，那麼整個HDFS就用不了了，所以就存在單點故障(single point of failure)；其次，若是須要升級或者維護中止NameNode，整個HDFS也用不了。爲了解決這個問題，採用了QJM機制(Quorum Journal Manager)實現HDFS的HA（High Availability）。注意，一開始採用的「共享存儲」機制，關於共享存儲機制的不足，可參考：（還提到了QJM的優勢）

In a typical HA cluster, two separate machines are configured as NameNodes.
At any point in time, exactly one of the NameNodes is in an Active state, and the other is in a Standby state. 
The Active NameNode is responsible for all client operations in the cluster, while the Standby is simply acting as a slave, 
maintaining enough state to provide a fast failover if necessary.

爲了實現HA，須要兩臺NameNode機器，一臺是Active NameNode，負責Client請求。另外一臺是StandBy NameNode，負責與Active NameNode同步數據，從而快速 failover。

那麼，這裏就有個問題，StandBy NameNode是如何同步Active NameNode上的數據的呢？主要同步是哪些數據呢？

數據同步就用到了Quorum機制。同步的數據 主要是EditLog。

In order for the Standby node to keep its state synchronized with the Active node, 
both nodes communicate with a group of separate daemons called 「JournalNodes」 (JNs). 

數據同步用到了一個第三方」集羣「：Journal Nodes。Active NameNode 和 StandBy NameNode 都與JournalNodes通訊，從而實現同步。

''''''''''''''''''''''''''''''''''

每次 NameNode 寫 EditLog 的時候，除了向本地磁盤寫入 EditLog 以外，也會並行地向 JournalNode 集羣之中的每個 JournalNode 發送寫請求，只要大多數 (majority) 的 JournalNode 節點返回成功就認爲向 JournalNode 集羣寫入 EditLog 成功。若是有 2N+1 臺 JournalNode，那麼根據大多數的原則，最多能夠容忍有 N 臺 JournalNode 節點掛掉。

這就是：Quorum機制。每次寫入JournalNode的機器數目達到大多數(W)時，就認爲本次寫操做成功了。

'''''''''''''''''''''''''''''''''

這樣，每次對Active NameNode中的元數據進行修改時，都會將該修改寫入JournalNode集羣的大多數機器中，才認爲這次修改爲功。

當Active NameNode宕機時，StandBy NameNode 向JournalNode同步EditLog，從而保證了HA。

Active NameNode 向 JournalNode 集羣提交 EditLog 是同步的
但 Standby NameNode 採用的是定時從 JournalNode 集羣上同步 EditLog 的方式，那麼 Standby NameNode 內存中文件系統鏡像有很大的多是落後於 Active NameNode 的，
因此 Standby NameNode 在轉換爲 Active NameNode 的時候須要把落後的 EditLog 補上來。

具體的同步過程可參考： Hadoop NameNode 高可用 (High Availability) 實現解析

 

In order to provide a fast failover, it is also necessary that the Standby node have up-to-date information
regarding the location of blocks in the cluster. In order to achieve this, the DataNodes are configured with the location of both NameNodes, 
and send block location information and heartbeats to both.

此外，爲了實現快速failover，StandBy NameNode 須要實時地與各個DataNode通訊以得到每一個數據塊的地址信息。爲咐要這樣？

由於：每一個數據塊的地址信息不屬於「元信息」，並無保存在 FsImage、CheckPoint...，這是由於地址信息變化比較大。好比說，一臺DataNode下線了，其上面的數據塊地址信息就全無效了，並且爲了達到指定的數據塊「複製因子」，還須要在其餘機器上覆制該數據塊。

而快速failover，是指Active NameNode宕機後，StandBy NameNode當即就能提供服務。所以，DataNode也須要實時向 StandBy NameNode 發送 block report

另外，還有手動failover 和 自動 failover，自動failover須要Zookeeper的支持，具體可參考官網：HDFS High Availability Using the Quorum Journal Manager

 

如何避免「Split Brain」(腦裂)問題？

Split Brain 是指在同一時刻有兩個認爲本身處於 Active 狀態的 NameNode。

when a NameNode sends any message (or remote procedure call) to a JournalNode, it includes its epoch number as part of the request. 
Whenever the JournalNode receives such a message, it compares the epoch number against a locally stored value called the promised epoch. 
If the request is coming from a newer epoch, then it records that new epoch as its promised epoch.
 If instead the request is coming from an older epoch, then it rejects the request. This simple policy avoids split-brain

簡單地理解以下：每一個NameNode 與 JournalNodes通訊時，須要帶一個 epoch numbers(epoch numbers 是惟一的且只增不減)。而每一個JournalNode 都有一個本地的promised epoch。擁有值大的epoch numbers 的NameNode會使得JournalNode提高本身的 promised epoch，從而佔大多數，而epoch numbers較小的那個NameNode就成了少數派(Paxos協議思想)。

從而epoch number值大的NameNode纔是真正的Active NameNode，擁有寫JournalNode的權限。注意：（任什麼時候刻只容許一個NameNode擁有寫JournalNode權限）

when using the Quorum Journal Manager, only one NameNode will ever be allowed to write to the JournalNodes,
so there is no potential for corrupting the file system metadata from a split-brain scenario.

具體實現可參考：（還提到了QJM的優勢）

 

四，參考資料

維基百科Quorum

https://issues.apache.org/jira/secure/attachment/12547598/qjournal-design.pdf

Hadoop2.6.0學習筆記（九）SPOF解決方案Quorum機制

HDFS HA與QJM[官網整理]

 

原文地址：http://www.cnblogs.com/hapjin/p/5626889.html