二：Paxos補充

分佈式系統中，最經典的問題就是如何作到分佈式環境下的數據一致性

對於這個問題產生了CAS，Base理輪，等經典理論的探討

那麼什麼是分佈式一致性：集羣中的狀態保持一致，不管訪問集羣中的那臺機器，返回的數據都是一致的，這就是最籠統的分佈式一致性。

一致性：強一致性，作不到

順序一致性：讀一個讀寫操做的集合全部進程看到的都是同樣的順序

因果一致性：顧名思義，保證全部因果操做關係的一致性

最終一致性：容許存在中間狀態，可是能夠保證數據最終的一致性

下面咱們來一看下載BackUp，Master/Salve,Master/Master/2pc,Paxos算法

1	Backups	M/S	MM	2PC	Paxos
Consistency(一致性)	Weak.
由於通常都是定時策略，因此會有很長時間的不一致	最終一致性	最終一致性	Strong	Strong
Transaction(事務)	不支持	Full	Local	Full	Full
Latency(延時)	高	低	低	高	高
throughput(吞吐量)	高	高	高	低	中等
Data loss	lots	Some	Some	None	None
Failover	Down	Read only	R/W	R/W	R/W

 

2pc：

    顧名思義，就是兩端提交，分爲PrePare和Do Commit兩個階段

    1：PrePare階段：協調者向集羣中的參與者發出Prepare請求，參與者選擇恢復（Yes/No）,進入這個階段後，參與者會記錄自己的狀態，而且保持一個阻塞狀態

    2：Do Commit階段：若是協調者接收到集羣內部全部機器Yes的話，就會發送一個Commit請求，若是有一個參與者不一樣意的話那麼就會通知回滾。

那麼在第一階段就能夠看出來，在參與者反饋後就開始處於阻塞的狀態，那麼若是有一個參與者掛掉了，那麼協調者就會等待，這就會致使效率問題，fh

此外協調者和參與者都有可能出錯，這就致使了不能夠高可用的問題

Paxos

角色：Proposer提議者，Acceptor批准者

完成一次算法以前，全部的Acceptor都處於一致狀態

他也是一種兩端提交協議

第一個階段：Prepare階段

 Proposer提議者發送一個Prepare階段，以議案的形式{"sn":n}

    a):若是Acceptor之前沒批准過如何議案，那麼就會直接返回ok

    b):若是Acceptor之前批准過議案，Acceptor會保留批准過的議案，本地{"sn":j,"value":"v1"},就會對比j和n的值，若是n>=j,那麼就會返回{「sn」:「j」，「value」:「v1」}，而且作出如下保證，不會再批准編號小於n的任何議案，若是j>n，那麼直接、、

第二個階段：Accept階段

       a）：若是發現多數又返回

            a1）：若是多數返回ok，那麼就會設定一個本身的值v2，發送議案{"sn"："n"，"value"："v2"}

            a2)：返回中有各類各樣的值，就會選擇一個最大的值，發送議案{"sn"："x"，"value"："x"}

    b）：若是多數Acceptor返回結果，那麼Proposer議案提議者就會認爲議案被接受，通知Learner進行學習，完成一次Proposer，不然再次提交。

最簡單的就是先學習，若是沒有的話就本身定義一個值，若是有返回，選取最大的一個值進行廣播，當大多數Acceptor認同了，就ok，通知Learner學習。

可是也有其缺陷的地方，容易出現活鎖的狀況，互相提交議案，

期間也不能修改v值

並且不能保證最早發起的議案會被執行。

改進以後：Fast

在集羣內部選舉出一個Leader，只有Leader能夠發起Proposer

開始一次算法的時候，Leader發起同步，負責收集消息，而後學習議案，進行廣播

知乎大牛的文章不錯

https://www.zhihu.com/question/19787937

Pasox made simple中文翻譯

http://blog.csdn.net/sparkliang/article/details/5740882