一、分散式系統的難點

分散式系統比起單機系統存在哪些難點呢？

1. 網路因素

由於服務和資料分佈在不同的機器上，每次互動都需要跨機器執行，這帶來如下幾個問題：

1. 網路延遲：效能、超時

同機房的網路IO還是比較塊的，但是跨機房，尤其是跨IDC，網路IO就成為不可忽視的效能瓶頸了。並且，延遲不是頻寬，頻寬可以隨便增加，千兆網絡卡換成萬兆，只是成本的問題，但延遲是物理限制，基本不可能降低。

這帶來的問題就是系統整體效能的降低，會帶來一系列的問題，比如資源的鎖住，所以系統呼叫一般都要設定一個超時時間進行自我保護，但是過度的延遲就會帶來系統的RPC呼叫超時，引發一個令人頭疼的問題：分散式系統呼叫的三態結果：成功、失敗、超時。不要小看這個第三態，這幾乎是所有分散式系統複雜性的根源。

針對這個問題有一些相應的解決方案：非同步化，失敗重試。 而對於跨IDC資料分佈帶來的巨大網路因素影響，則一般會採用資料同步，代理專線等處理方式。

2. 網路故障：丟包、亂序、抖動。

這個可以通過將服務建立在可靠的傳輸協議上來解決，比如TCP協議。不過帶來的是更多的網路互動。因此是效能和流量的一個trade off。這個在移動網際網路中更需要考慮。

2. 魚與熊掌不可兼得——CAP定律

CAP理論是由Eric Brewer提出的分散式系統中最為重要的理論之一：

1. Consistency：[強]一致性，事務保障，ACID模型。
2. Availiablity：[高]可用性，冗餘以避免單點，至少做到柔性可用（服務降級）。
3. Partition tolerance：[高]可擴充套件性（分割槽容忍性）：一般要求系統能夠自動按需擴充套件，比如HBase。

CAP原理告訴我們，這三個因素最多隻能滿足兩個，不可能三者兼顧。對於分散式系統來說，分割槽容錯是基本要求，所以必然要放棄一致性。對於大型網站來說，分割槽容錯和可用性的要求更高，所以一般都會選擇適當放棄一致性。對應CAP理論，NoSQL追求的是AP，而傳統資料庫追求的是CA，這也可以解釋為什麼傳統資料庫的擴充套件能力有限的原因。

在CAP三者中，“可擴充套件性”是分散式系統的特有性質。分散式系統的設計初衷就是利用叢集多機的能力處理單機無法解決的問題。當需要擴充套件系統性能時，一種做法是優化系統的效能或者升級硬體(scale up)，一種做法就是“簡單”的增加機器來擴充套件系統的規模(scale out)。好的分散式系統總在追求”線性擴充套件性”，即效能可以隨叢集數量增長而線性增長。

可用性和可擴充套件性一般是相關聯的，可擴充套件行好的系統，其可用性一般會比較高，因為有多個服務(資料)節點，不是整體的單點。所以分散式系統的所有問題，基本都是在一致性與可用性和可擴充套件性這兩者之間的一個協調和平衡。對於沒有狀態的系統，不存在一致性問題，根據CAP原理，它們的可用性和分割槽容忍性都是很高，簡單的新增機器就可以實現線性擴充套件。而對於有狀態的系統，則需要根據業務需求和特性在CAP三者中犧牲其中的一者。一般來說，交易系統類的業務對一致性的要求比較高，一般會採用ACID模型來保證資料的強一致性，所以其可用性和擴充套件性就比較差。而其他大多數業務系統一般不需要保證強一致性，只要最終一致就可以了，它們一般採用BASE模型，用最終一致性的思想來設計分散式系統，從而使得系統可以達到很高的可用性和擴充套件性。

CAP定律其實也是衡量分散式系統的重要指標，另一個重要的指標是效能。

一致性模型

主要有三種：

1. Strong Consistency（強一致性）：新的資料一旦寫入，在任意副本任意時刻都能讀到新值。比如：檔案系統，RDBMS，Azure Table都是強一致性的。
2. Week Consistency（弱一致性）：不同副本上的值有新有舊，需要應用方做更多的工作獲取最新值。比如Dynamo。
3. Evantual Consistency（最終一致性）：一旦更新成功，各副本的資料最終將達到一致。

從這三種一致型的模型上來說，我們可以看到，Weak和Eventually一般來說是非同步冗餘的，而Strong一般來說是同步冗餘的(多寫)，非同步的通常意味著更好的效能，但也意味著更復雜的狀態控制。同步意味著簡單，但也意味著效能下降。

以及其他變體：

1. Causal Consistency（因果一致性）：如果Process A通知Process B它已經更新了資料，那麼Process B的後續讀取操作則讀取A寫入的最新值，而與A沒有因果關係的C則可以最終一致性。
2. Read-your-writes Consistency（讀你所寫一致性）：如果Process A寫入了最新的值，那麼 Process A的後續操作都會讀取到最新值。但是其它使用者可能要過一會才可以看到。
3. Session Consistency（會話一致性）：一次會話內一旦讀到某個值，不會讀到更舊的值。
4. Monotonic Read Consistency（單調一致性）：一個使用者一旦讀到某個值，不會讀到比這個值更舊的值，其他使用者不一定。

等等。

其中最重要的變體是第二條：Read-your-Writes Consistency。特別適用於資料的更新同步，使用者的修改馬上對自己可見，但是其他使用者可以看到他老的版本。Facebook的資料同步就是採用這種原則。

二、分散式系統常用技術和應用場景

• consistent hashing [with virtual node]：一致性雜湊，資料分佈
• vector clock：時鐘向量，多版本資料修改
• Quorum W+R>N [with vector clock]：抽屜原理，資料一致性的另一種解決方案。時鐘向量，多版本資料修改。
• Merkle tree [with anti-entropy]：資料複製
• MVCC：copy-on-write與snapshot
• 2PC/3PC：分散式事務
• Paxos：強一致性協議
• Symmetry and Decentralization：對稱性和去中心化。對稱性(symmetry)簡化了系統的配置和維護。去中心化是對對稱性的延伸，可以避免master單點，同時方便叢集scale out。
• Map-Reduce：分而治之；移動資料不如移動計算。將計算儘量排程到與儲存節點在同一臺物理機器上的計算節點上進行，這稱之為本地化計算。本地化計算是計算排程的一種重要優化。
• Gossip協議：節點管理
• Lease機制：

consistent hashing：一致性雜湊，解決資料均衡分佈問題

我們通常使用的hash演算法是hash() mod n，但是如果發生某個節點失效時，無法快速切換到其他節點。為了解決單點故障的問題，我們為每個節點都增加一個備用節點，當某個節點失效時，就自動切換到備用節點上，類似於資料庫的master和slave。但是依然無法解決增加或刪除節點後，需要做hash重分佈的問題，也就是無法動態增刪節點。這時就引入了一致性hash的概念 ，將所有的節點分佈到一個hash環上，每個請求都落在這個hash環上的某個位置，只需要按照順時針方向找到的第一個節點，就是自己需要的服務節點。當某個節點發生故障時，只需要在環上找到下一個可用節點即可。

一致性hash演算法最常用於分散式cache中，比如注意的memcached。Dynamo也用其作為資料分佈演算法，並且對一致性演算法進行了改進，提出了基於虛擬節點的改進演算法，其核心思路是引入虛擬節點，每個虛擬節點都有一個對應的物理節點，而每個物理節點可以對應若干個虛擬節點。

關於一致性hash的更多內容，可以參考筆者另一篇博文：Memcached的分散式演算法學習。

virtual node

前面說過，有的Consistent Hashing的實現方法採用了虛擬節點的思想。使用一般的hash函式的話，伺服器的對映地點的分佈非常不均勻。因此，使用虛擬節點的思想，為每個物理節點（伺服器）在continuum上分配100～200個點。這樣就能抑制分佈不均勻，最大限度地減小伺服器增減時的快取重新分佈。

Quorum W+R>N：抽屜原理，資料一致性的另一種解決方案

N: 複製的節點數，即一份資料被儲存的份數。 R: 成功讀操作的最小節點數，即每次讀取成功需要的份數。 W: 成功寫操作的最小節點數 ，即每次寫成功需要的份數。

所以 W+R>N的意思是：對於有N份拷貝的分散式系統，寫到W(W<=N)份成功算寫成功，讀R(R<=N)份資料算讀成功。

這三個因素決定了可用性，一致性和分割槽容錯性。W+R>N可以保證資料的一致性(C)，W越大資料一致性越高。這個NWR模型把CAP的選擇權交給了使用者，讓使用者自己在功能，效能和成本效益之間進行權衡。

對於一個分散式系統來說，N通常都大於3，也就說同一份資料需要儲存在三個以上不同的節點上，以防止單點故障。W是成功寫操作的最小節點數，這裡的寫成功可以理解為“同步”寫，比如N=3，W=1，那麼只要寫成功一個節點就可以了，另外的兩份資料是通過非同步的方式複製的。R是成功讀操作的最小節點數，讀操作為什麼要讀多份資料呢？在分散式系統中，資料在不同的節點上可能存在著不一致的情況，我們可以選擇讀取多個節點上的不同版本，來達到增強一致性的目的。

NWR模型的一些設定會造成髒資料和版本衝突問題，所以一般要引入vector clock演算法來解決這個問題。

需要保證系統中有max(N-W+1,N-R+1)個節點可用。

關於NWR模型，建議閱讀 分散式系統的事務處理，寫的很通俗易懂。

vector clock：時鐘向量，多版本資料修改

lease機制

chubby、zookeeper 獲得lease（租約）的節點得到系統的承諾：在有效期內資料/節點角色等是有效的，不會變化的。

lease機制的特點：

• lease頒發過程只需要網路可以單向通訊，同一個lease可以被頒發者不斷重複向接受方傳送。即使頒發者偶爾傳送lease失敗，頒發者也可以簡單的通過重發的辦法解決。
• 機器宕機對lease機制的影響不大。如果頒發者宕機，則宕機的頒發者通常無法改變之前的承諾，不會影響lease的正確性。在頒發者機恢復後，如果頒發者恢復出了之前的lease 資訊，頒發者可以繼續遵守lease的承諾。如果頒發者無法恢復lease資訊，則只需等待一個最大的lease超時時間就可以使得所有的lease都失效，從而不破壞lease機制。
• lease機制依賴於有效期，這就要求頒發者和接收者的時鐘是同步的。
  • 如果頒發者的時鐘比接收者的時鐘慢，則當接收者認為lease已經過期的時候，頒發者依舊認為lease有效。接收者可以用在lease到期前申請新的lease的方式解決這個問題。
  • 如果頒發者的時鐘比接收者的時鐘快，則當頒發者認為lease已經過期的時候，可能將lease頒發給其他節點，造成承諾失效，影響系統的正確性。對於這種時鐘不同步，實踐中的通常做法是將頒發者的有效期設定得比接收者的略大，只需大過時鐘誤差就可以避免對lease的有效性的影響。

工程中，常選擇的lease時長是10秒級別，這是一個經過驗證的經驗值，實踐中可以作為參考並綜合選擇合適的時長。

雙主問題（腦裂問題）

lease機制可以解決網路分割槽問題造成的“雙主”問題，即所謂的“腦裂”現象。配置中心為一個節點發放lease，表示該節點可以作為primary節點工作。當配置中心發現primary有問題時，只需要等到前一個primary的lease過期，就可以安全地頒發新的lease給新的primary節點，而不會出現“雙主”問題。 在實際系統中，若用一箇中心節點作為配置中心傳送lease也有很大的風險。實際系統總是使用多箇中心節點互為副本，成為一個小的叢集，該小叢集具有高可用性，對外提供頒發lease的功能。chubby和zookeeper都是基於這樣的設計。

chubby一般有五臺機器組成一個叢集，可以部署成兩地三機房。chubby內部的五臺機器需要通過Paxos協議選取一個chubby master機器，其它機器是chubby slave，同一時刻只有一個chubby master。chubby相關的資料，比如鎖資訊，客戶端的session資訊等都需要同步到整個叢集，採用半同步的做法，超過一半的機器成功就可以回覆客戶端。最後可以確保只有一個和原有的chubby master保持完全同步的chubby slave被選取為新的chubby master。

Gossip協議

Gossip用於P2P系統中自治節點獲悉對叢集認識（如叢集的節點狀態，負載情況等）。 系統中的節點定期互相八卦，很快八卦就在整個系統傳開了。 A、B兩個節點八卦的方式主要是：A告訴B知道哪些人的什麼八卦；B告訴A這些八卦裡B知道哪些更新了；B更新A告訴他的八卦...... 說是自治系統，其實節點中還有一些種子節點。種子節點的作用主要是在有新節點加入系統時體現。新節點加入系統中，先與種子節點八卦，新節點獲得系統資訊，種子節點知道系統中多了新節點。其他節點定期與種子節點八卦的時候就知道有新節點加入了。 各個節點互相八卦的過程中，如果發現某個節點的狀態很長時間都沒更新，就認為該節點已經宕機了。

Dynamo使用了Gossip協議來做會員和故障檢測。

2PC、3PC、Paxos協議: 分散式事務的解決方案

分散式事務很難做，所以除非必要，一般來說都是採用最終一致性來規避分散式事務。

目前底層NoSQL儲存系統實現分散式事務的只有Google的系統，它在Bigtable之上用Java語言開發了一個系統 Megastore，實現了兩階段鎖，並通過Chubby來避免兩階段鎖協調者宕機帶來的問題。Megastore實現目前只有簡單介紹，還沒有相關論文。

2PC

實現簡單，但是效率低，所有參與者需要block，throughput低；無容錯，一個節點失敗整個事務失敗。如果第一階段完成後，參與者在第二階沒有收到決策，那麼資料結點會進入“不知所措”的狀態，這個狀態會block住整個事務。

3PC

改進版的2PC，把2PC的第一個段break成了兩段: 詢問，然後再鎖資源，最後真正提交。3PC的核心理念是：在詢問的時候並不鎖定資源，除非所有人都同意了，才開始鎖資源。

3PC比2PC的好處是，如果結點處在P狀態（PreCommit）的時候發生了Fail/Timeout的問題，3PC可以繼續直接把狀態變成C狀態（Commit），而2PC則不知所措。

不過3PC實現比較困難，而且無法處理網路分離問題。如果preCommit訊息傳送後兩個機房斷開，這時候coordinator所在的機房會abort，剩餘的participant會commit。

Paxos

Paxos的目的是讓整個叢集的結點對某個值的變更達成一致。Paxos演算法是一種基於訊息傳遞的一致性演算法。Paxos演算法基本上來說是個民主選舉的演算法——大多數的決定會成個整個叢集的統一決定。

任何一個點都可以提出要修改某個資料的提案，是否通過這個提案取決於這個叢集中是否有超過半數的結點同意（所以Paxos演算法需要叢集中的結點是單數）。這個是Paxos相對於2PC和3PC最大的區別，在2f+1個節點的叢集中，允許有f個節點不可用。

Paxos的分散式民主選舉方式，除了保證資料變更的一致性之外，還常用於單點切換，比如Master選舉。

Paxos協議的特點就是難，both 理解 and 實現 :(

關於2PC，3PC和Paxos，強烈推薦閱讀 分散式系統的事務處理。

目前大部分支付系統其實還是在2PC的基礎上進行自我改進的。一般是引入一個差錯處理器，進行差錯協調（回滾或者失敗處理）。

MVCC：多版本併發控制

這個是很多RDMS儲存引擎實現高併發修改的一個重要實現機制。具體可以參考：

Map-Reduce思想

1. 分而治之

2. 移動資料不如移動計算

如果計算節點和儲存節點位於不同的物理機器則計算的資料需要通過網路傳輸，此種方式的開銷很大。另一種思路是，將計算儘量排程到與儲存節點在同一臺物理機器上的計算節點上進行，這稱之為本地化計算。本地化計算是計算排程的一種重要優化。

經典論文和分散式系統學習

Dynamo

HBase

LSM Tree

• LSM（Log Structured Merge Trees）是B+ Tree一種改進
• 犧牲了部分讀效能，用來大幅提高寫效能
• 思路：拆分樹
  • 首先寫WAL，然後記錄資料到入到記憶體中，構建一顆有序子樹(memstore)
  • 隨著子樹越來越大，記憶體的子樹會flush到磁碟上(storefile)
  • 讀取資料：必須遍歷所有的有序子樹（不知資料在哪棵子樹）
  • Compact：後臺執行緒對磁碟中的子樹進行歸併，變成大樹（子樹多了讀得慢）

事實上，lucene的索引機制也類似HBase的LSM樹。也是寫的時候分別寫在單獨的segment，後臺進行segement合併。

參考文件

http://blog.arganzheng.me/posts/thinking-in-distributed-systems.html