Paxos算法與Zookeeper分析,zab (zk)raft協議(etcd) 8. 與Galera及MySQL Group replication的比較

 

 

 mit 分佈式論文集 https://github.com/feixiao/Distributed-Systems

wiki上描述的幾種都明白了就出師了

raft 和 zab 是相似的,都是1.先選舉,2.而後再對客戶端的消息進行投票.  實際上是 simple paxos 的一種變化.

和 原生paxos 的區別在於: 選舉的階段實際上是 prepare 的階段. 選舉容許多個主出現.

1. 讀原文

paxos-simple-Copy [ https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/paxos-simple-Copy.pdf ]

讀譯文

悟出一點和zk的區別.

文獻例子中:

• • leader能夠兩個, 全部投票仍是兩階段. prepare預鎖[預鎖是最好的理解方式]+ 提交 因此在fast paxos中再次強調不關心leader如何選舉[The Progress Property 一節中,i will not discuss how to select leader]. 在此文中有說起方法,timeout.[paxos-simple-Copy原文Progress 一節末尾]
  • 順序性有序號保證,接受不必定當即執行. 故沒有135 ,就不能執行149. 能夠先設置一個nop
  • 能夠批量決議議題,第x-x+10個命令,是否採用對應的命令.
  • instance 就是沒個決議. 筆者注:instance能夠細化到到單個帳戶的投票上,對應着zk爲各個路徑.增長併發能力.

zk和raft中leader的做用:

       1. 做爲全部paxos instance的prepare階段. [phil注: 通常人悟不到這點]

2. 統籌全部的請求,方便進行併發控制

3. 選擇日誌最多的節點,可以快速從失敗中恢復.

 

zk和raft中leader是否可能有多個?

zk:

可能的. 雖然zk在獲得半數贊成後, 再等待了finalizeWait = 200ms, 遠當心節點之間心跳超時時間. 也避免不了leader被搶走的尷尬. 案例說明: 共5臺機器, 好比 1,2,3 都選擇了1. 1 變成leader 而後2 還沒獲得3的通知, 此時5發出請求,獲得了2,3,4,5的贊成.

raft:

選本身,而後通知全部人. 各自等待. 先喚醒的再選擇本身,通知全部人.

zk:

和raft共同點:

• • 　　有選舉輪次,來源於simple paxos 的prepare的概念
  • 都是選本身,通知全部人.

和raft不一樣點:

• • 對返回的結果不理睬,直接睡眠 [4]
  • leader排他,有效的只能是一個.
  • 順序性有命令隊列保證.
  • 接受了當即執行
  • 日誌不是順序的
  • 加入新節點會阻塞 [1]
  • 更換leader會阻塞 [1]

    http://blog.csdn.net/xhh198781/article/details/10949697 前半部分是對simple faxos的很好總結.

   raft:

和zk共同點:

• • 有選舉輪次,來源於simple paxos 的prepare的概念

和raft不一樣點:

• • 對返回的結果理睬.
  • 日誌是連續的 [1] [3]
  • 加入新節點不阻塞
    • 其餘區別見下圖[6]

       

  
  

   

       

 

筆者註解: 以前的可靠性都是

1. 經過備份,切換的方式. 對應的監聽切換器又須要熱備. 熱備無窮盡也.

2. 客戶端多ip 適用於無狀態服務器.

       paxos的選舉機制很好的解決了這個問題.3臺機器便可. 客戶端配置x個ip.

 

• paxos之Multi-Paxos 這個沒找到原文獻. 和simple中思想差異較大.可是和zk區別較大,見[2]

• FastPaxos 有原文獻.
• 趣事Paxos在大型系統中常見的應用場景

「Leslie Lamport也是用了長達9年的時間來完善這個算法的理論」–

這個故事實際上是這樣的:
Lamport大牛在他Paxos的第一個版本早在1990年就提交給ACM TOCS Jnl.的評審委員會了 可是當時沒有人理解他的算法 主編回執他的稿子建議他用數學而不是神話描述他的算法 他們纔會考慮接受這篇paper 

Lamport大牛很生氣 他有次就在一個會議上說:」爲何搞理論的這羣人一點幽默感也沒有呢?」 他拒絕修改 並且withdraw了這篇文章

1996年微軟的Butler Lampson在WDAG96上提出了從新審視這篇文章 由於他讀懂了

1997年MIT的Nancy Lynch在WDAG97上 根據原文從新改寫了這篇文章 叫作 在本文中她們」代替」Lamport用數學形式化的定義並證實了Paxos

因而在1998年的ACM TOCS上 這篇遲到了9年的paper終於被接受了

後來2001年 Lamport大牛也做出了讓步 他用簡單的語言而不是神話故事 重述了原文 這就是 可是通篇仍是沒有數學符號 L大牛甚爲執拗 據他本身說 他檢查過了本身的語言並無歧義 不須要數學來描述

Paxos能夠說是Theory of CS領域被流傳最普遍的一則趣事~

 

•  實現:

phxsql）是騰訊開源的mysql主備集羣多副本管理系統，除了mysql源碼以外，還包含了一系列外部的組件（phxsqlproxy、phxbinlogsvr）和內部插件（phxsync），藉助paxos協議，實現了主備數據的強一致。

• • • MySQL半同步複製的數據一致性探討   
    • 談談PhxSQL的設計和實現哲學（下）8. 與Galera及MySQL Group replication的比較
    • 世界上目前已知的通過理論證實和實際檢驗的一致性算法屈指可數：兩階段提交two-phase commit (2PC)、Paxos[4]、Raft[5]、Zookeeper Atomic Broadcast (ZAB)[3]、Viewstamped Replication[5]等。newsql
    • zk的zap 說明
    • raft說明

阿里雲企業三節點版本，在alisql內核中引入raft協議，不借助任何外部依賴，經過mysqld自身的簡單配置，實現整個集羣的構建，架構簡單、實現優雅。

•  paxos一些例子和進階,事務《分佈式系統理論基礎 - 時間、時鐘和事件順序》

分佈式基礎通訊協議:paxos,totem和gossip canssandra.

•  P2P大規模直播與GOSSIP協議 百度文庫上仍是有好文章的. 看看學術文章,對理解新技術仍是不錯的.

• 2. zk的原理

    核心是對應的畫圖能力,模塊分解能力. 數據流圖.

    別人的文章 圖解zookeeper FastLeader選舉算法. 要學會畫無職責的流程圖(含循環+ 節點批註). 而後再理解模塊,帶上職責. 甚至是角色.

   Paxos算法與Zookeeper分析

    http://blog.csdn.net/zhxdick/article/details/50886638

[1] Raft對比ZAB協議  總結了兩個經典區別: 1. 日誌的連續性問題 2.加入過程是否阻塞整個請求  .具體詳見文獻3

[2] Multi Paxos http://www.cnblogs.com/fei33423/p/7990190.html wiki上也有,可是沒有對應的文獻.

[3] Raft算法賞析  核心: 當前term的leader不能「直接」提交以前term的entries . 致使了日誌是連續的

   有一張例子圖 

[4] Raft 爲何是更易理解的分佈式一致性算法

[5] 頗有深度的文章 分佈式系統理論進階 - Raft、Zab

[6] Vive La Difference: Paxos vs. Viewstamped Replication vs. Zab, Robbert van Renesse, Nicolas Schiper and Fred B. Schneider, 2014

我的渣記錄,僅搜索用