理解分布式一致性:Paxos协议之Cheap Paxos Fast Paxos
理解分布式一致性:Paxos協議之Cheap Paxos & Fast Paxos
- Cheap Paxos
- Message flow: Cheap Multi-Paxos
- Fast Paxos
- Message flow: Fast Paxos, non-conflicting
- Message flow: Fast Paxos, conflicting proposals
- Message flow: Fast Paxos with uncoordinated recovery, collapsed roles
在前面一篇文章我們講到了理解分布式一致性:Paxos協議之Multi-Paxos,本篇文章我會講解Paxos協議的另外兩個變種:Cheap Paxos和Fast Paxos。
Cheap Paxos
Cheap Paxos 是Basic Paxos 的繼承版本。其實所有的Paxos變種都來自與Basic Paxos,都是基于它來進行改進的。那么Cheap Paxos有什么特點呢?
在Basic Paxos中,我們知道,共識如果想要正常進行的話,出錯的節點數目必須小于n/2, 也就是說必須要有大于n/2的節點正常運行才能共識成功。節點運行就不可避免的會占用資源,有沒有什么辦法可以即節省資源又可以保證節點正常共識呢?
辦法就是Cheap Paxos:我們在Cheap Paxos里面引入了輔助節點的概念,輔助節點只有在必須需要它來達成共識的情況下才會啟動。舉個例子,如果我們總共有N+1個節點,那么我們只能夠忍受N/2個節點出錯,否則系統不能達成共識。但是當我們再引入N個輔助節點,即使有N個節點出錯,只要額外的N個輔助節點啟動并正常工作,就能達成共識并保證系統的正常運行,輔助節點在正常節點恢復工作后會自動停止,這樣只是在必要的時候才啟動輔助資源,就大大的解約了分布式系統的成本,所以叫它Cheap Paxos.
Message flow: Cheap Multi-Paxos
下圖是3個正常節點+1個輔助節點的流程,如果系統規定的共識節點個數是3個,那么當一個正常節點掛掉之后,輔助節點會起來幫助完成共識工作。
ProposerAcceptor1Acceptor2Acceptor3Aux-- Phase 2 --Accept!(1,I,V)Accept!(1,I,V)Accept!(1,I,V)Accepted(1,I,V)Accepted(1,I,V)Acceptor3 is down共識數目不夠,重發請求給輔助節點Accept!(1,I,V)Accept!(1,I,V)Accept!(1,I,V)Accepted(1,I,V)Accepted(1,I,V)Accepted(1,I,V)共識成功,將最小共識節點減一,停止輔助節點繼續下一輪Accept!(1,I+1,W)Accept!(1,I+1,W)Accepted(1,I+1,W)Accepted(1,I+1,W)ProposerAcceptor1Acceptor2Acceptor3AuxFast Paxos
在之前提到的Paxos協議中,消息最后到達Learner一般都要經歷 Client–>Proposer–>Acceptor–>Learner 總共3個步驟。
那么有沒有更快的方法讓消息到達Learner呢?畢竟Learner是真正執行任務的,我們希望這個任務更加快速的為Learner所知。方法就是如果Proposer本身沒有數據需要被確認的話,那么Client可以直接發送Accept請求給Acceptor,從而跳過Proposer這一步,這樣的操作叫做Fast Paxos。
這里還要注意一點,Client 發送請求給Proposer是直接發送給Leader,也就是發送一次就夠了,但是發給Acceptor的話就要所有的Acceptors都發一遍。
Message flow: Fast Paxos, non-conflicting
下圖列出了正常運行的情況,沒有沖突正常執行。
ClientLeaderAcceptor1Acceptor2Acceptor3Acceptor4LearnerAccept!(N,I,W)Accept!(N,I,W)Accept!(N,I,W)Accept!(N,I,W)Accepted(N,I,W)Accepted(N,I,W)Accepted(N,I,W)Accepted(N,I,W)Accepted(N,I,W)Accepted(N,I,W)Accepted(N,I,W)Accepted(N,I,W)Response(W)ClientLeaderAcceptor1Acceptor2Acceptor3Acceptor4LearnerMessage flow: Fast Paxos, conflicting proposals
當有多個Client同時發送Accept請求的時候就有可能產生沖突。這時候有兩種解決辦法。
Message flow: Fast Paxos with uncoordinated recovery, collapsed roles
下圖是所有的角色集合到一個Server的情況,是更加簡潔的實現。
Client1Client2Server1Server2Server3Server4Accept!(N,I,V)Accept!(N,I,V)Accept!(N,I,V)Accept!(N,I,V)Accept!(N,I,W)Accept!(N,I,W)Accept!(N,I,W)Accept!(N,I,W)Accepted(N,I,V)Accepted(N,I,V)Accepted(N,I,W)Accepted(N,I,W)Servers檢測到沖突,直接根據協議自行解決,這里選擇W為最終結果Accepted(N+1,I,W)Accepted(N+1,I,W)Accepted(N+1,I,W)Accepted(N+1,I,W)Response(W)Response(W)Client1Client2Server1Server2Server3Server4更多精彩內容且看:
- 區塊鏈從入門到放棄系列教程-涵蓋密碼學,超級賬本,以太坊,Libra,比特幣等持續更新
- Spring Boot 2.X系列教程:七天從無到有掌握Spring Boot-持續更新
- Spring 5.X系列教程:滿足你對Spring5的一切想象-持續更新
- java程序員從小工到專家成神之路(2020版)-持續更新中,附詳細文章教程
更多教程請參考flydean的博客
超強干貨來襲 云風專訪:近40年碼齡,通宵達旦的技術人生總結
以上是生活随笔為你收集整理的理解分布式一致性:Paxos协议之Cheap Paxos Fast Paxos的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 理解分布式一致性:Raft协议
- 下一篇: 理解分布式一致性:Paxos协议之Gen