實例分析分布式數(shù)據(jù)存儲協(xié)議對比

　　關(guān)于一致性

　　為什么需要Paxos或Quorum算法？分布式系統(tǒng)實現(xiàn)數(shù)據(jù)存儲，是通過多份數(shù)據(jù)副本來保證可靠，假設(shè)部分節(jié)點訪問數(shù)據(jù)失敗，還有其他節(jié)點提供一致的數(shù)據(jù)返回給用戶。對數(shù)據(jù)存儲而言，怎樣保證副本數(shù)據(jù)的一致性當屬分布式存儲最重要的問題。 一致性是分布式理論中的根本性問題，近半個世紀以來，科學家們圍繞著一致性問題提出了很多理論模型，依據(jù)這些理論模型，業(yè)界也出現(xiàn)了很多工程實踐投影。何為一致性問題？簡而言之，一致性問題就是相互獨立的節(jié)點之間，在可控的時間范圍內(nèi)如何達成一項決議的問題。

　　強一致寫、多段式提交

　　強一致寫

　　解決這個問題最簡單的方法 ，就是強一致寫。在用戶提交寫請求后，完成所有副本更新再返回用戶，讀請求任意選擇某個節(jié)點。數(shù)據(jù)修改少節(jié)點少時，方案看起來很好，但操作頻繁則有寫操作延時問題，也無法處理節(jié)點宕機。

　　兩段式提交（2PC 、Three-Phase Commit）

　　既然實際系統(tǒng)中很難保證強一致，便只能通過兩段式提交分成兩個階段，先由Proposer（提議者）發(fā)起事物并收集Acceptor（接受者）的返回，再根據(jù)反饋決定提交或中止事務(wù)。

　　第一階段：Proposer發(fā)起一個提議，詢問所有Acceptor是否接受；

　　第二階段：Proposer根據(jù)Acceptor的返回結(jié)果，提交或中止事務(wù)。如果Acceptor全部同意則提交，否則全部終止。

　　兩階段提交方案是實現(xiàn)分布式事務(wù)的關(guān)鍵；但是這個方案針對無反饋的情況，除了“死等”，缺乏合理的解決方案。 Proposer在發(fā)起提議后宕機，階段二的Acceptor資源將鎖定死等。如果部分參與者接受請求后異常，還可能存在數(shù)據(jù)不一致的腦裂問題。

　　三段式提交（3PC、Three-Phase Commit）

　　為了解決2PC的死等問題，3PC在提交前增加一次準備提交（prepare commit）的階段，使得系統(tǒng)不會因為提議者宕機不知所措。接受者接到準備提交指令后可以鎖資源，但要求相關(guān)操作必須可回滾。

　　但3PC并沒有被用在我們的工程實現(xiàn)上，因為3PC無法避免腦裂，同時有其他協(xié)議可以做到更多的特性又解決了死等的問題。

　　圖1 三段式提交，在二段式提交基礎(chǔ)上增加prepare commit階段

　　主流的Paxos算法

　　微信后臺近期開始主要推廣Paxos算法用于內(nèi)部分布式存儲。Paxos是Leslie Lamport提出的基于消息傳遞的一致性算法，解決了分布式存儲中多個副本響應(yīng)讀寫請求的一致性，Paxos在目前的分布式領(lǐng)域幾乎是一致性的代名詞（據(jù)傳Google Chubby的作者Mike Burrows曾說過這個世界上只有一種一致性算法， 那就是Paxos，其他算法都是殘次品）。Paxos算法在可能宕機或網(wǎng)絡(luò)異常的分布式環(huán)境中，快速且正確地在集群內(nèi)部對某個數(shù)據(jù)的值達成一致，并且保證只要任意多數(shù)節(jié)點存活，都不會破壞整個系統(tǒng)的一致性。Paxos的核心能力就是多個節(jié)點確認一個值，少數(shù)服從多數(shù)，獲得可用性和一致性的均衡。