現(xiàn)代的互聯(lián)網(wǎng)已經(jīng)進入大數(shù)據(jù)時代，每天都有數(shù)以萬計的數(shù)據(jù)產(chǎn)生，這些數(shù)據(jù)的規(guī)模輕輕松松地可以達到幾P的級別，傳統(tǒng)的的單機存儲早已捉襟見肘，根本無法滿足大數(shù)據(jù)對存儲系統(tǒng)的要求。這時，各種分布式系統(tǒng)才應運而生。
其實分布式的概念，早在很多年前，就有人提出和進行相關研究，但是由于當時的網(wǎng)絡數(shù)據(jù)很少，分布式無用武之地，一直不溫不火，一至到大數(shù)據(jù)時代的來臨，才陸陸續(xù)續(xù)被人們應用到工程實踐中。
概念
分布式存儲系統(tǒng)，是將數(shù)據(jù)分散存儲在多臺獨立的設備上。傳統(tǒng)的網(wǎng)絡存儲系統(tǒng)采用集中的存儲服務器存放所有數(shù)據(jù)，存儲服務器成為系統(tǒng)性能的瓶頸，也是可靠性和安全性的焦點，不能滿足大規(guī)模存儲應用的需要。分布式網(wǎng)絡存儲系統(tǒng)采用可擴展的系統(tǒng)結構，利用多臺存儲服務器分擔存儲負荷，利用位置服務器定位存儲信息，它不但提高了系統(tǒng)的可靠性、可用性和存取效率，還易于擴展。
分布式存儲系統(tǒng)的特性
可擴展
分布式存儲系統(tǒng)可以擴展到幾百臺甚至幾千臺的集群規(guī)模，而且隨著集群規(guī)模的增長，系統(tǒng)整體性能表現(xiàn)為線性增長。
低成本
分布式存儲系統(tǒng)的自動容錯、自動負載均衡機制使其可以構建在普通的PC機之上。另外，線性擴展能力也使得增加、減少機器非常方便，可以實現(xiàn)自動運維。
高性能
無論是針對整個集群還是單臺服務器，都要求分布式存儲系統(tǒng)具備高性能。
易用
分布式存儲系統(tǒng)需要能夠提供易用的對外接口，另外，也要求具備完善的監(jiān)控、運維工具，并能夠文玩 與其他系統(tǒng)集成。
技術難點
分布式存儲系統(tǒng)的挑戰(zhàn)主要在于數(shù)據(jù)、狀態(tài)信息的持久化，要求在自動遷移、自動容錯、并發(fā)讀寫的過程中保證數(shù)據(jù)的一致性。分布式存儲涉及的技術主要來自兩個領域：分布式系統(tǒng)以及數(shù)據(jù)庫。
數(shù)據(jù)分布
如何將數(shù)據(jù)分布到多臺服務器才能保證數(shù)據(jù)分布均勻？數(shù)據(jù)分布到多臺服務器后如何實現(xiàn)跨服務器讀寫操作？
分布式系統(tǒng)區(qū)別于傳統(tǒng)單機系統(tǒng)在于能夠將數(shù)據(jù)分布到多個節(jié)點，并在多個節(jié)點之間實現(xiàn)負載均衡。分布式存儲系統(tǒng)的一個基本要求就是透明性，包括數(shù)據(jù)分布透明性， 數(shù)據(jù)遷移透明性，數(shù)據(jù)復制透明性還有數(shù)據(jù)故障透明性。
哈希分布
哈希分布的方法很常見，其方法是根據(jù)數(shù)據(jù)的某一特征計算哈希值，并將哈希值與集群中的服務器建立映射關系，從而將不同哈希值的數(shù)據(jù)分布到不同的服務器上。如果哈希函數(shù)的散列性很好，哈希方式可以將數(shù)據(jù)比較均勻地分布到集群中去，而且哈希方式需要記錄的元信息也很簡單，每個節(jié)點只需要知道哈希函數(shù)的計算方式以及模的服務器的個數(shù)就可以計算出處理的數(shù)據(jù)應該屬于哪臺機器。
傳統(tǒng)的哈希分布算法有一個問題，當服務器上線或者下線時，N值發(fā)生變化，數(shù)據(jù)映射會被打亂。為解決這個問題，一個辦法是不再簡單地將哈希值和服務器個數(shù)做除法映射，而是將哈希值與服務器的對應關系作為元數(shù)據(jù)，交給專門的元數(shù)據(jù)服務器來管理。還有一個辦法是采用一致性哈希算法。
一致性哈希（Distributed Hash Table,DHT）算法。算法思想：給系統(tǒng)中每個節(jié)點分配一個隨機token，這些token構成一個哈希環(huán)。執(zhí)行數(shù)據(jù)存放操作時，先計算Key的哈希值，然后存放到順時針方向第一個大于或者等于該哈希值的token 所在的節(jié)點。一致性哈希值的優(yōu)點在于加入或刪除時只會影響到在哈希環(huán)中相除的節(jié)點，而對其它節(jié)點沒影響。
順序分布
哈希散列破壞了數(shù)據(jù)的有序性，只支持隨機讀取操作，不能支持順序掃描。而且這種方式可能出現(xiàn)某些用戶的數(shù)據(jù)量太大的問題，由于用戶的數(shù)據(jù)限定在一個存儲節(jié)點，無法發(fā)揮分布式存儲系統(tǒng)的多機并行處理能力。
順序分布在分布式表格系統(tǒng)中比較常見，一般的做法是將大表順序劃分為連續(xù)的范圍，每個范圍稱為一個子表，總控服務器負責將這些子表按照一定的策略分配到存儲節(jié)點上。
一致性
如果將數(shù)據(jù)的多個副本復制到多臺服務器，即使在異常情況下，也能夠保證不同副本之間的數(shù)據(jù)一致性。同一份數(shù)據(jù)的多個副本往往有一個副本為主副本，其他副本為備副本，由主副本將數(shù)據(jù)復制到備份副本。復制協(xié)議分為兩種，強同步復制以及異步復制，二者的區(qū)別在于用戶的讀寫請求是否需要同步到備副本才可以返回成功。假如備份副本不止一個，復制協(xié)議還會要求寫請求至少需要同步到幾個備副本。當主副本出現(xiàn)故障時，分布式存儲系統(tǒng)能夠將服務自動切換到某個備副本，實現(xiàn)自動容錯。
一致性和可用性是矛盾的，強同步復制協(xié)議可以保證主備副本之間的一致性，但是當備副本出現(xiàn)故障時，也可能阻塞存儲系統(tǒng)的正常寫服務，系統(tǒng)的整體可用性受到影響；異步復制協(xié)議的可用性相對較好，但是一致性得不到保障，主副本出現(xiàn)故障時還有數(shù)據(jù)丟失的可能。
強同步與異步復制
分布式存儲系統(tǒng)中數(shù)據(jù)保存多個副本，一般來說，其中一個副本為主副本，其他副本為備副本，常見的做法是數(shù)據(jù)寫入到主副本，由主副本確定操作的順序并復制到其他副本。
客戶端將寫請求發(fā)送給主副本，主副本將寫請求復制到其他備副本，常見的做法是同步操作日志（Commit log）。主副本首先將操作日志同步到備副本上備副本回放操作日志，完成后通知主副本。接著主副本修改本機，等到所有的操作都完成后再通知客戶端寫成功。這里要求主備同步成功后才可以返回客戶端寫成功，這種協(xié)議稱為強同步協(xié)議。強同步協(xié)議提供了強一致性，但是，如果備副本出現(xiàn)問題將阻塞寫操作，系統(tǒng)可用性較差。
與強同步對應的復制方式是異步復制。在異步模式下，主副本不需要等待備副本的回應，只需要本地修改成功就可以告知客戶端寫操作成功。另外，主副本通過異步機制，比如單獨的復制線程將客戶端修改操作推送到其他副本。異步復制的好處在于系統(tǒng)可用性好，但是一致性差，如果主副本發(fā)生不可恢復故障，可能丟失最后一部分更新操作。
強同步復制和異步復制都是將主副本的數(shù)據(jù)以某種形式發(fā)送到其他副本，這種復制協(xié)議稱為基于主副本的復制協(xié)議。這種方法要求在任何時刻只能有一個副本為主副本，由它來確定寫操作之間的順序。如果主副本出現(xiàn)故障，需要選舉一個備副本成為新的主副本，這步操作稱為選舉，如Paxos協(xié)議。除此外還有基于多個存儲節(jié)點的復制協(xié)議（比較少見）。
操作日志的原理很簡單：為了利用好磁盤的順序讀寫特性，將客戶端的寫操作先順序寫入到磁盤中，然后應用到內存中，由于內存是隨機讀寫設備，可以很容易通過各種數(shù)據(jù)結構，比如B+樹將數(shù)據(jù)有效地組織起來.當服務器宕機重啟時，只需要積攢一定的操作日志再批量寫入到磁盤中，這種技術一般稱為成組提交。
CAP
CAP即一致性（Consistency）、可用性（Availablility）以及分區(qū)可容忍性（Tolerance of network Partition）三者不能同時滿足。
一致性：讀操作總是能讀取到之前完成的寫操作結果，滿足這個條件的系統(tǒng)稱為強一致性系統(tǒng)，這里的“之前”一般對同一個客戶端而言。
可用性：讀寫操作在單臺機器發(fā)生故障的情況下仍然能夠正執(zhí)行，而不需要等待發(fā)生故障重啟或者其上的服務遷移到其他機器。
分區(qū)可容忍性：機器故障、網(wǎng)絡故障、機房停電等異常情況下仍然能夠滿足一致性和可用性。
分布式存儲系統(tǒng)要求能夠自動容錯，分區(qū)容忍性總是要滿足的，因此，一致性和寫操作的可用性不能同時滿足。存儲系統(tǒng)設計時需要在一致性和可用性之間權衡，在某些場景下，不允許丟失數(shù)據(jù)，在另外一些場景下，極小概率丟失部分數(shù)據(jù)是允許的，可用性更加重要。
容錯
如何檢測到服務器故障？如何自動將出現(xiàn)故障的服務器上的數(shù)據(jù)和服務器遷移到集群中的其它服務器？
隨著集群規(guī)模變得越來越大，故障發(fā)生的概率也越來越大，大規(guī)模集群每天都有故障發(fā)生。容錯是分布式存儲系統(tǒng)設計的重要目標，只在實現(xiàn)了自動化容錯，才能減少人工成本，實現(xiàn)分布式存儲的規(guī)模效應。
故障檢測
單臺服務器故障的概率是不高的，然而，只要集群的規(guī)模足夠大， 每天都有機器故障發(fā)生，系統(tǒng)需要能夠自動處理。首先，分布式存儲系統(tǒng)需要能夠檢測到機器故障，在分布式系統(tǒng)中，故障檢測往往通過租約（Lease）協(xié)議實現(xiàn)。接著，需要能夠將服務器復制或者遷移到集群中的其他正常服務的存儲節(jié)點。
租約機制就是帶有超時間的一種授權。假設機器A需要檢測機器B 是否發(fā)生故障，機器A 可以給機器B 發(fā)放租約， 機器B 持有的租約在有效期內才允許提供服務，否則主動停止服務。機器B 的租約快要到期時向機器A 重新申請租約。正常情況下，機器B 通過不斷申請租約來延長有效期，當機器B 出現(xiàn)故障或者與機器A 之初蝗網(wǎng)絡發(fā)生故障時，機器B 租約將過期，從而機器A 能夠確保機器B 不再提供服務，機器B 的服務可以被安全地遷移到其他服務器。
故障恢復
單層結構和雙層結構的故障恢復機制有所不同。
單層結構。單層結構的分布式存儲系統(tǒng)維護了多個副本，主備副本之間通過操作日志同步。節(jié)點下線分為兩種情況：一種是臨時故障，節(jié)點過一段時間將重新上線；另一種情況是永久性故障，比如硬盤損壞。
雙層結構。雙層結構的分布式存儲系統(tǒng)會將所有的數(shù)據(jù)持久化寫入底層的分布式文件系統(tǒng)，每個數(shù)據(jù)片同一時刻只有一個提供服務的節(jié)點。
節(jié)點故障會影響系統(tǒng)服務，在故障檢測以及故障恢復的過程中，不能提供寫服務以及強一致性讀服務。停服務時間包含兩個部分，故障檢測時間故障恢復時間。故障檢測時間一般在幾秒到十幾秒， 這和集群規(guī)模密切相關，集群規(guī)模越大，故障檢測對總控節(jié)點造成的壓力就越大，故障檢測時間就越長。故障恢復時間一般很短，單層結構的備副和主副本之間保持實時同步，切換為主副本的時間很短;雙層結構故障恢復往往實現(xiàn)成只需要將數(shù)據(jù)的索引，而不是所有的數(shù)據(jù)加載到內存中。
總控節(jié)點自身也可能出現(xiàn)故障，為了實現(xiàn)總控節(jié)點的高可用性，總控節(jié)點的狀態(tài)也將實時同步到備機，當故障發(fā)生時， 可以通過外部服務選舉某個備機作為新的總控節(jié)點，而這個外部服務也必須是高可用的。為了進行選主或者維護系統(tǒng)中重要的全局信息，可以維護一套通過Paxos 協(xié)議實現(xiàn)的分布式鎖服務， 如Zookeeper。
負載均衡
新增服務器和集群正常運行過程中如何實現(xiàn)自動負載均衡？數(shù)據(jù)遷移過程中如何保證不影響已有服務？
分布式存儲系統(tǒng)的每個集群中一般有一個總控節(jié)點，其他節(jié)點為工作節(jié)點，由總控節(jié)點根據(jù)全局負載信息進行整體調度。工作節(jié)點剛上線時，總控節(jié)點需要將數(shù)據(jù)遷移到該節(jié)點上，另外，系統(tǒng)運行過程中也需要不斷地執(zhí)行遷移任務，將數(shù)據(jù)從負載較高的工作節(jié)點遷移到負載較低的工作節(jié)點。
工作節(jié)點通過心跳包，將節(jié)點負載相關的信息，如CPU、內存、磁盤及網(wǎng)絡等資源使用率，讀寫次數(shù)及讀寫數(shù)據(jù)量等發(fā)給主控節(jié)點。主控節(jié)點計算出工作節(jié)點的負載信息以及需要遷移的數(shù)據(jù)，生成遷移任務放入遷移隊列中等待執(zhí)行。
負載均衡需要執(zhí)行數(shù)據(jù)遷移操作。在分布式存儲系統(tǒng)中往往會存儲數(shù)據(jù)的多個副本，一個為主副本，其他為備副本，由主副本對外提供服務。遷移備副本不會對服務造成影響，遷移主副本也可以首先將數(shù)據(jù)的讀寫服務切換到其他備副本。整個遷移過程可以做到無縫，對用戶完全透明。
分布式協(xié)議
分布式系統(tǒng)涉及的協(xié)議很多,例如租約、復制協(xié)議、一致性協(xié)議等等，其中以兩階段提交協(xié)議和Paxos 協(xié)議最具有代表性。兩階段提交協(xié)議用于保證跨多個節(jié)點操作的原子性，即跨多個節(jié)點的操作要么在所有節(jié)點上全部執(zhí)行成功，要么全部失敗。Paxos 協(xié)議用于確保多個節(jié)點對某個投票（如選取某個節(jié)點為主節(jié)點）達成一致。
兩階段提交協(xié)議
兩階段提交協(xié)議（Two-phase Commit，2PC）經(jīng)常用來實現(xiàn)分布式事務，在兩階段協(xié)議中，系統(tǒng)一般包含兩類節(jié)點：一類為協(xié)調者（coordinator），通常一個系統(tǒng)中只有一個；另一類為事務參與者（participants，cohorts或者workers），一般包含多個。協(xié)議中假設每個節(jié)點都會記錄操作日志并持久化到非易失性存儲介質，即使節(jié)點發(fā)生故障日志也不會丟失。執(zhí)行過程如下：
-
第一階段，準備階段。協(xié)調者通知事務參與者準備提交或者取消事務，然后進入表決過程。在表決過程中，參與者將告知協(xié)調者自己的決策，同意（事務參與者本地執(zhí)行成功）或者取消（事務參與者本地執(zhí)行失敗）。可以進一步將準備階段分為以下三個步驟：
協(xié)調者節(jié)點向所有參與者節(jié)點詢問是否可以執(zhí)行提交操作(vote)，并開始等待各參與者節(jié)點的響應。
參與者節(jié)點執(zhí)行詢問發(fā)起為止的所有事務操作，并將Undo信息和Redo信息寫入日志。（注意：若成功這里其實每個參與者已經(jīng)執(zhí)行了事務操作）
各參與者節(jié)點響應協(xié)調者節(jié)點發(fā)起的詢問。如果參與者節(jié)點的事務操作實際執(zhí)行成功，則它返回一個”同意”消息；如果參與者節(jié)點的事務操作實際執(zhí)行失敗，則它返回一個”中止”消息。
-
第二階段，提交階段。協(xié)調者將基于第一個階段的投票結果進行決策，提交或者取消。當且僅當所有的參與者同意提交事務協(xié)調者才通知所有的參與者提交事務，否則協(xié)調者通知所有的參與者取消事務。參與者在接收到協(xié)調者發(fā)來的的消息后將執(zhí)行相應的操作。
提交：
調者節(jié)點向所有參與者節(jié)點發(fā)出”正式提交(commit)”的請求。
參與者節(jié)點正式完成操作，并釋放在整個事務期間內占用的資源。
參與者節(jié)點向協(xié)調者節(jié)點發(fā)送”完成”消息。
協(xié)調者節(jié)點受到所有參與者節(jié)點反饋的”完成”消息后，完成事務。
取消：
協(xié)調者節(jié)點向所有參與者節(jié)點發(fā)出”回滾操作(rollback)”的請求。
參與者節(jié)點利用之前寫入的Undo信息執(zhí)行回滾，并釋放在整個事務期間內占用的資源。
參與者節(jié)點向協(xié)調者節(jié)點發(fā)送”回滾完成”消息。
協(xié)調者節(jié)點受到所有參與者節(jié)點反饋的”回滾完成”消息后，取消事務。
二階段提交看起來確實能夠提供原子性的操作，但是不幸的事，二階段提交還是有幾個缺點的：
同步阻塞問題。執(zhí)行過程中，所有參與節(jié)點都是事務阻塞型的。當參與者占有公共資源時，其他第三方節(jié)點訪問公共資源不得不處于阻塞狀態(tài)。
單點故障。由于協(xié)調者的重要性，一旦協(xié)調者發(fā)生故障。參與者會一直阻塞下去。尤其在第二階段，協(xié)調者發(fā)生故障，那么所有的參與者還都處于鎖定事務資源的狀態(tài)中，而無法繼續(xù)完成事務操作。（如果是協(xié)調者掛掉，可以重新選舉一個協(xié)調者，但是無法解決因為協(xié)調者宕機導致的參與者處于阻塞狀態(tài)的問題）
數(shù)據(jù)不一致。在二階段提交的階段二中，當協(xié)調者向參與者發(fā)送commit請求之后，發(fā)生了局部網(wǎng)絡異常或者在發(fā)送commit請求過程中協(xié)調者發(fā)生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之后就會執(zhí)行commit操作。但是其他部分未接到commit請求的機器則無法執(zhí)行事務提交。于是整個分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)部一致性的現(xiàn)象。
二階段無法解決的問題：協(xié)調者再發(fā)出commit消息之后宕機，而唯一接收到這條消息的參與者同時也宕機了。那么即使協(xié)調者通過選舉協(xié)議產(chǎn)生了新的協(xié)調者，這條事務的狀態(tài)也是不確定的，沒人知道事務是否被已經(jīng)提交。
由于二階段提交存在著諸如同步阻塞、單點問題、腦裂等缺陷，所以，研究者們在二階段提交的基礎上做了改進，提出了三階段提交（三階段提交也是不完美的，這里不再贅述）。
Paxos 協(xié)議
Paxos 協(xié)議用于解決多個節(jié)點之間的一致性問題。多個節(jié)點之間通過操作日志同步數(shù)據(jù)，如果只有一個節(jié)點為主節(jié)點，那么，很容易確保多個節(jié)點之間操作日志的一致性。只要保證了多個節(jié)點之間操作日志的一致性，就能夠在這些節(jié)點上構建高可用的全局服務，如分布式鎖服務，全局命名和配置服務等。
為了實現(xiàn)高可用性，主節(jié)點往往將數(shù)據(jù)以操作日志的形式同步到備節(jié)點。如果主節(jié)點發(fā)生故障，備節(jié)點會提議自己成為主節(jié)點。Paxos 協(xié)議保證，即使同時存在多個proposer，也能保證所有節(jié)點最終達到一致，選舉出唯一的主節(jié)點。下面引用網(wǎng)上一篇博客的內容來講述Paxos協(xié)議。
在paxos算法中，分為4種角色：Proposer（提議者）、Acceptor（決策者）、Client（產(chǎn)生議題者）和Learner（最終決策學習者）。其中提議者和決策者是很重要的，其他的2個角色在整個算法中應該算做打醬油的，Proposer就像Client的使者，由Proposer使者拿著Client的議題去向Acceptor提議，讓Acceptor來決策。這里上面出現(xiàn)了個新名詞：最終決策。現(xiàn)在來系統(tǒng)的介紹一下paxos算法中所有的行為：
Proposer提出議題
Acceptor初步接受 或者 Acceptor初步不接受
如果上一步Acceptor初步接受則Proposer再次向Acceptor確認是否最終接受
Acceptor 最終接受 或者Acceptor 最終不接受
上面Learner最終學習的目標是Acceptor們最終接受了什么議題？注意，這里是向所有Acceptor學習，如果有多數(shù)派個Acceptor最終接受了某提議，那就得到了最終的結果，算法的目的就達到了。過程如下圖：
現(xiàn)在通過一則故事來學習paxos的算法的流程(2階段提交)，有2個Client(老板，老板之間是競爭關系)和3個Acceptor(政府官員)。
第一階段：
現(xiàn)在需要對一項議題來進行paxos過程，議題是“A項目我要中標！”，這里的“我”指每個帶著他的秘書Proposer的Client老板。
Proposer當然聽老板的話了，趕緊帶著議題和現(xiàn)金去找Acceptor政府官員。
作為政府官員，當然想誰給的錢多就把項目給誰。
Proposer-1小姐帶著現(xiàn)金同時找到了Acceptor-1~Acceptor-3官員，1與2號官員分別收取了10比特幣，找到第3號官員時，沒想到遭到了3號官員的鄙視，3號官員告訴她，Proposer-2給了11比特幣。不過沒關系，Proposer-1已經(jīng)得到了1,2兩個官員的認可，形成了多數(shù)派(如果沒有形成多數(shù)派，Proposer-1會去銀行提款在來找官員們給每人20比特幣，這個過程一直重復每次+10比特幣，直到多數(shù)派的形成)，滿意的找老板復命去了，但是此時Proposer-2保鏢找到了1,2號官員，分別給了他們11比特幣，1,2號官員的態(tài)度立刻轉變，都說Proposer-2的老板懂事，這下子Proposer-2放心了，搞定了3個官員，找老板復命去了，當然這個過程是第一階段提交，只是官員們初步接受賄賂而已。故事中的比特幣是編號，議題是value（這個過程保證了在某一時刻，某一個proposer的議題會形成一個多數(shù)派進行初步支持）。
現(xiàn)在進入第二階段提交：
現(xiàn)在proposer-1小姐使用分身術(多線程并發(fā))分了3個自己分別去找3位官員，最先找到了1號官員簽合同，遭到了1號官員的鄙視，1號官員告訴他proposer-2先生給了他11比特幣，因為上一條規(guī)則的性質proposer-1小姐知道proposer-2第一階段在她之后又形成了多數(shù)派(至少有2位官員的贓款被更新了);此時她趕緊去提款準備重新賄賂這3個官員(重新進入第一階段)，每人20比特幣。剛給1號官員20比特幣， 1號官員很高興初步接受了議題，還沒來得及見到2,3號官員的時候。
這時proposer-2先生也使用分身術分別找3位官員(注意這里是proposer-2的第二階段)，被第1號官員拒絕了告訴他收到了20比特幣，第2,3號官員順利簽了合同，這時2，3號官員記錄client-2老板用了11比特幣中標，因為形成了多數(shù)派，所以最終接受了Client2老板中標這個議題，對于proposer-2先生已經(jīng)出色的完成了工作；
這時proposer-1小姐找到了2號官員，官員告訴她合同已經(jīng)簽了，將合同給她看，proposer-1小姐是一個沒有什么職業(yè)操守的聰明人，覺得跟Client1老板混沒什么前途，所以將自己的議題修改為“Client2老板中標”，并且給了2號官員20比特幣，這樣形成了一個多數(shù)派。順利的再次進入第二階段。由于此時沒有人競爭了，順利的找3位官員簽合同，3位官員看到議題與上次一次的合同是一致的，所以最終接受了，形成了多數(shù)派，proposer-1小姐跳槽到Client2老板的公司去了。
Paxos過程結束了，這樣，一致性得到了保證，算法運行到最后所有的proposer都投“client2中標”所有的acceptor都接受這個議題，也就是說在最初的第二階段，議題是先入為主的，誰先占了先機，后面的proposer在第一階段就會學習到這個議題而修改自己本身的議題，因為這樣沒職業(yè)操守，才能讓一致性得到保證，這就是paxos算法的一個過程。原來paxos算法里的角色都是這樣的不靠譜，不過沒關系，結果靠譜就可以了。該算法就是為了追求結果的一致性。
其他
易用性。如何設計對外接口使得系統(tǒng)容易使用？如何設計監(jiān)控系統(tǒng)并將系統(tǒng)的內部狀態(tài)以方便的形式暴露給運維人員？
壓縮與解壓縮。如何根據(jù)數(shù)據(jù)的特點設計合理的壓縮與解壓縮算法？如何平衡壓縮算法節(jié)省的存儲空間和消耗的CPU計算資源。
分布式存儲系統(tǒng)分類
分布式存儲系統(tǒng)需要存儲的數(shù)據(jù)多種多樣，大致上可分為：非結構化數(shù)據(jù)，如文本文件、圖片、視頻和音頻等格式；結構化數(shù)據(jù)，一般存在關系數(shù)據(jù)庫中，可以用二維關系表結構來表示，模式與內容是分開的；半結構化數(shù)據(jù)，如HTML文檔，模式結構與內容是放在一起的。
不同的分布式存儲系統(tǒng)適合存儲不同的數(shù)據(jù)。
分布式文件系統(tǒng)
互聯(lián)網(wǎng)應用需要存儲大量的圖片、照片和視頻等非結構化數(shù)據(jù)對象，這類數(shù)據(jù)以對象的形式組織，對象之間沒有關聯(lián)，這樣的數(shù)據(jù)一般稱為Blob(Binary large object)數(shù)據(jù)。
分布式文件系統(tǒng)適合存儲Blob對象，典型的如谷歌的GFS以及它的開源實現(xiàn)HDFS。在系統(tǒng)實現(xiàn)層面，分布式文件系統(tǒng)內部按照數(shù)據(jù)塊（chunk）來組織數(shù)據(jù)，每個數(shù)據(jù)塊的大小相同，每個數(shù)據(jù)塊可以包含我個Blob 對象或者定長塊，一個大文件也可以拆分成多個數(shù)據(jù)塊。
分布式鍵值系統(tǒng)
分布式鍵值系統(tǒng)存儲關系簡單的半結構化數(shù)據(jù)，它只提供主鍵的CRUD功能，如Dynamo、Redis和Memcache。從數(shù)據(jù)結構來看，分布式鍵值系統(tǒng)與傳統(tǒng)的哈希表比較類似，不同的是，分布式系統(tǒng)支持將數(shù)據(jù)分布到集群中的多個存儲結點。分布式鍵值系統(tǒng)是分布式表格系統(tǒng)的一種簡化實現(xiàn)，一般用作緩存。一致性哈希是分布式鍵值系統(tǒng)中常用的數(shù)據(jù)分布技術。
分布式表格系統(tǒng)
分布式表格系統(tǒng)用于存儲關系較為復雜的半結構化數(shù)據(jù)，與分布式鍵值系統(tǒng)相比，分布式表格系統(tǒng)不僅僅支持簡單的CRUD 操作，而且支持掃描某個主鍵范圍。分布式表格系統(tǒng)以表格為單位組織數(shù)據(jù)，每個表格包括很多行，通過主鍵標識一行，支持根據(jù)主鍵的CRUD功能以及范圍查找功能。
分布式表格系統(tǒng)借鑒了很多關系數(shù)據(jù)庫的技術，例如支持某種程度上的事務。典型的系統(tǒng)如Bigtable、HBase和DynamoDB。與分布式數(shù)據(jù)庫相比，分布式表格系統(tǒng)主要針對單張表格的操作，不支持一些特別復雜的操作，比如多表關聯(lián)、多表連接、嵌套子查詢。而且在分布式表格系統(tǒng)中，同一個表格的多個數(shù)據(jù)行也不要求包含相同類型的列，適合半結構化數(shù)據(jù)。分布式表格系統(tǒng)是一種很好的權衡，這類系統(tǒng)可以做到超大規(guī)模，而且支持較多的功能，但實現(xiàn)往往比較復雜。
分布式數(shù)據(jù)庫
分布式數(shù)據(jù)庫一般是從單機關系數(shù)據(jù)庫擴展而來，用于存儲結構化數(shù)據(jù)。分布式數(shù)據(jù)庫采用二維表格組織數(shù)據(jù)，提供SQL關系查詢語言，支持多表關聯(lián)，嵌套子查詢等復雜操作，并提供數(shù)據(jù)庫事務以及并發(fā)控制。典型的如MySQL數(shù)據(jù)庫集群、Amazon RDS及Microsoft SQL Azure。
參考：
