丨zab協(xié)議如何實現(xiàn)操作的順序性

我們分別創(chuàng)建了配置"/geekbang"和"/geekbang/time"，對應(yīng)的值分別為123和456。那么在這里我提個問題：你覺得在ZooKeeper中，能用蘭伯特的Multi-Paxos實現(xiàn)各節(jié)當然不行。因為蘭伯特的Mti-Paos（也就是操作）B協(xié)議著力解決的，也是理解B不過，雖然大家都在提ZAB協(xié)議，但是在我看來，ZAB協(xié)議和ZooKeeper代碼耦合在一起，也就是說，你是無法單獨使用ZAB協(xié)議的，所以一般而言，只需要理解ZAB協(xié)議的架構(gòu)和基礎(chǔ)原理就可以了，不需要對代碼和細節(jié)做太多的深究。所以，我會從ZAB協(xié)議的為什么Multi-Paxosi-Paxos解決的是一系列值如何達成共識的問題，它關(guān)心的是，對于指定序號的位置，最多只有一個指令（Command這么說可能比較抽象，為了方便你理解，我舉個具體的例子演示一下（一個3節(jié)點的Multi-Paxos），為了演示方便，我們假設(shè)當前所有節(jié)點被選定的指令的最大序號為100，也就是說，新提議的指令對應(yīng)的序號將為101。假設(shè)這時節(jié)點A故障了，新當選的者為節(jié)點B。節(jié)點B當選者后，需要先作為學（A102B），那么它可以101Z，指令Z功到節(jié)點B、C這時節(jié)點B故障了，節(jié)點A恢復了，出者C后，節(jié)點B故障也恢復了。節(jié)點C當選者后，需要先作為學習者，了解目前已被選定的指令，這時它執(zhí)行BasicPaxos的準備階段，就會發(fā)現(xiàn)之前選定的值（比如Z、Y），然后發(fā)送接受請求，最終在序號101、102處達成共識的指令是Z、Y。就像下圖的樣子。在這里，你可以看到，原本預期的指令是X、Y，最后變成了Z、Y，也就是說，雖然Multi-Paxos比如，假設(shè)在ZooKeeper中直接使用了的Multi-Paxos，這時咱們創(chuàng)建節(jié)代代[zk:localhost:2181(CONNECTED)6]create/geekbang/timeNodedoesnotexist:在這里我多說幾句，有很多關(guān)于分布式的理論，這些理論都很經(jīng)典（庭將問題、Paxos），但也因為太早了，與實際場景結(jié)合的不多，所以后續(xù)的眾多算法是在這個基礎(chǔ)之上做了大量的改進（比如，PBRaft）。關(guān)于這一點，我在3另外我還想補充一下，在我看來，在ZAB中，關(guān)于Paxos問題（Figure1）ZooKeeperMulti-PaxosBasicPaxos。對于Multi-Paxos而言，者作為唯一提議者，不存在同時多個提議者的情況。也就是說，Multi-Paxos無法保證操作的順序性的問題是存在的，但原因不是文中演示的原因，本質(zhì)上是因為Multi-PaxosMulti-PaxosZooKeeper你可能會說了：Multi-Paxos無法實現(xiàn)操作的順序性，但Raft可以啊，為什么ZooKeeperRaftRaft2013年才正式提出，在2007年開發(fā)ZooKeeper的時候，還沒有Raft呢。ZAB與的Multi-Paxos不同，ZAB不是共識算法，不基于狀態(tài)機，而是基于主備模式的這里我說的主備，就是tr-e模型，一個主節(jié)點和多個備份節(jié)點，所有副本的數(shù)據(jù)都以主節(jié)點為準，主節(jié)點采用二階段提交，向備份節(jié)點同步數(shù)據(jù)，如果主節(jié)點發(fā)生故障，數(shù)據(jù)最完備的節(jié)點將當選主節(jié)點。而原子廣播協(xié)議，你可以理解成廣播一組消息，消息的順序是固定的。需要你注意的是，ZAB在這里了個優(yōu)化，為了實現(xiàn)分區(qū)容錯能力，將數(shù)據(jù)到大多數(shù)節(jié)點后（也就是如果大多數(shù)節(jié)點準備好了），者就入提行階通知節(jié)執(zhí)行提交操作。在這一點上，Raft和ZAB是類似的，我建議你可以對比著Raft算法來理解ZAB。講到這兒我再多說一句，前面幾講的留言中有同學問狀態(tài)機的事情：在Mti-PaosRaft中為什么需要狀態(tài)機？這是一個很棒的問題，為你的深入思考點個贊！所以咱們先來看一下這個問題。本質(zhì)上來說，狀態(tài)機指的是有限狀態(tài)機，它是一個數(shù)學模型。你可以這么理解：狀態(tài)機是一個功能模塊，用來處理一系列請求，最大的特點就是確定性，也就是說，對于相同的輸入，不管重復運行多少次，最終的內(nèi)部狀態(tài)和輸出都是相同的。就像你敲擊鍵盤，在Word文檔上打字一樣，你敲擊鍵盤的順序決定了Word文檔上的文那么為什么在Multi-Paxos、Raft你想一下，Multi-Paxos、Raft都是共識算法，而共識算法是就一系列值達成共識的，達成共識后，這個值就不能改了。但有時候我們是需要更改數(shù)據(jù)的值的，比如KV，我們肯定需要更改指定key（比如X）對應(yīng)的值，這時我們就可以通過狀態(tài)機來解決這個問題。比如，如果你想把X的值改為7，那你可以提議一個新的指令“SETX=7”，當這個指令被達成共識并提交到狀態(tài)機后，你查詢到的值就是7了，也就成功修改了X的值。后，咱們說回剛剛的話題：ZAB協(xié)議如何保證操作的順序性？其次，ZAB實現(xiàn)了FIFO另外，ZAB還實現(xiàn)了當主節(jié)點后，只有日志最完備的節(jié)點才能當選主節(jié)點，因為日志你看，ZAB學到這里，想必你已經(jīng)發(fā)現(xiàn)了，這些特性好像和Raft很像。是的，因為面幾講，我們已經(jīng)學習了Raft算法，所以你可以類比Raft來理解，在Raft中：地，然后按照順序，到其他節(jié)點和提交;狀態(tài)機最大的特點是確定性，對于相同的輸入不管運行多少次，最終的內(nèi)部狀態(tài)和輸出都是相同的。需要你注意的是，在共識算法中，我們可以通過提議新的指令，達成共識后，提交給狀態(tài)機執(zhí)行，來達到修改指定內(nèi)容的效果，比如修改KV定yZAB是通過“一切以者為準”的強者模型和嚴格按照順序提交日志，來實現(xiàn)操作的順序性的，這一點和Raft是一樣的。最后說的是，的i-Paxos只考慮了如何實現(xiàn)共識，也就是，如何就一系列值達成共識，未考慮如何實現(xiàn)各值（也就是操作）的順序性。最終Kr主備模式的原子廣播協(xié)議，保證了操作的順序性，而且，BRaftRaft除了能就一些值達成共識，還能保證各值的順序性。學習完本講內(nèi)容后，你可以看到，RaftB（導者、跟隨者模型）、日志必須是連續(xù)的、以者的日志為準是日志一致等等。你可以想一下，那為什么它們會比較類似呢？我的看法是，所見略同。比如B議要實現(xiàn)操作的順序性，而Raft目不僅僅是操作的順序性，而是線性一致性，這兩個目標，都決定了它們不能允許日志不連續(xù)，照順交日那么們就過上方法日志序性（也就是提交）我提到在ZAB中，寫操作必須在主節(jié)點上執(zhí)行，主節(jié)點是通過簡化版的二階段提交向備份 售賣。頁面已增加防盜追蹤，將依 上一 14|PoW算法：有辦法黑比特幣嗎寫寫1 5r保證在一定的時間段內(nèi)，客戶端最終一定能夠從服務(wù)端上到的數(shù)據(jù)狀態(tài)。2應(yīng)該可以吧，雖然ZAB協(xié)議中Lead