轉載請註明出處 http://www.paraller.com
原文排版地址 點擊獲取更好閱讀體驗算法
應用場景:在分佈式系統中,每一個節點雖然能夠知曉本身的操做時成功或者失敗,卻沒法知道其餘節點的操做的成功或失敗。
當一個事務跨越多個節點時,爲了保持事務的 ACID 特性,須要引入一個做爲協調者的組件來統一掌控全部節點(稱做參與者)的操做結果並最終指示這些節點是否要把操做結果進行真正的提交(好比將更新後的數據寫入磁盤等)。數據庫
一、同步阻塞操做,必然會很是大地影響性能。網絡
二、另外是超時問題,好比,框架
糟糕的狀況是,第二階段中,若是參與者收不到協調者的 commit/fallback 指令,參與者將處於「狀態未知」階段,參與者徹底不知道要怎麼辦,好比:若是全部的參與者完成第一階段的回覆後(可能所有 yes,可能所有 no,分佈式
可能部分 yes 部分 no),若是協調者在這個時候掛掉了。那麼全部的結點徹底不知道怎麼辦(問別的參與者都不行)。爲了一致性,要麼死等協調者,要麼重發第一階段的 yes/no 命令。
(事務及分佈式事務)[http://blog.daocloud.io/micro...]性能
CAP 定理:一個分佈式系統最多隻能同時知足一致性
(Consistency)、可用性
(Availability)和分區容錯性
(Partition tolerance)這三項中的兩項。網站
一致性指更新操做成功後,全部節點在同一時間的數據徹底一致。常見的一致性類別:搜索引擎
常見的分佈式系統中,總會發生諸如機器宕機或網絡異常(包括消息的延遲、丟失、重複、亂序,還有網絡分區)等狀況。設計
Paxos 算法須要解決的問題就是如何在一個可能發生上述異常的分佈式系統中,快速且正確地在集羣內部對某個數據的值達成一致,而且保證不論發生以上任何異常,都不會破壞整個系統的一致性。
Raft是斯坦福的 Diego Ongaro、John Ousterhout 兩我的以易懂(Understandability)爲目標設計的一致性算法,在 2013 年發佈了論文:In Search of an Understandable Consensus Algorithm
從 2013 年發佈到如今不過只有兩年,到如今已經有了十多種語言的 Raft 算法實現框架code