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