摘要：底層網(wǎng)絡(luò)有一個(gè)，負(fù)責(zé)為每個(gè)消息加上一個(gè)序列號(hào)，為了防止故障或者失效，需要一個(gè)來(lái)進(jìn)行監(jiān)控。且論文作者在真實(shí)的環(huán)境下測(cè)試得到，對(duì)于這樣一個(gè)三層胖樹結(jié)構(gòu)的網(wǎng)絡(luò)，的情況下，添加一個(gè)序列號(hào)并不會(huì)增加額外的延遲開銷，的情況下，只有的延遲。

??首先標(biāo)題有點(diǎn)嘩眾取寵之嫌，但是暫時(shí)想不到更加合適的標(biāo)題，就姑且這么使用吧。分布式共識(shí)算法一直是一個(gè)熱門的研究話題，之所以要分布式共識(shí)，無(wú)外乎就是單點(diǎn)服務(wù)容易宕機(jī)，異常，出錯(cuò)，從而導(dǎo)致系統(tǒng)不可用，于是就有了備份容錯(cuò)的機(jī)制，那么一份數(shù)據(jù)多地(location)存儲(chǔ)，如果不發(fā)生修改操作那就無(wú)需一致性協(xié)議的引入，但是這僅僅是理想情況，真實(shí)的應(yīng)用中絕大多數(shù)都是需要執(zhí)行更新操作的，這才有了分布式共識(shí)的需求。目前最為認(rèn)同的共識(shí)算法就是lamport大神在98年發(fā)表的論文中提及的Paxos協(xié)議(然而由于太難以理解又在01年發(fā)表了paxos made simple)，即使過(guò)了這么多年，Paxos依然難以理解和難以實(shí)現(xiàn)，工程實(shí)現(xiàn)大多都是精簡(jiǎn)版，最為出名的也有Raft，以及Zookeeper中的Zab。筆者之前讀過(guò)paxos made simple，雖然能理解，但是總覺得有點(diǎn)一知半解(也寫了一篇小博客理解paxos協(xié)議-分布式共識(shí)算法（consensus）)。最近剛好看了一篇新的論文，結(jié)合Paxos來(lái)重新梳理下什么是分布式共識(shí)算法，怎么實(shí)現(xiàn)分布式共識(shí)算法。

??Just Say NO to Paxos Overhead:Replacing Consensus with Network Ordering 這篇論文是2016年osdi上的一篇論文，第一作者是華盛頓大學(xué)計(jì)算機(jī)系統(tǒng)實(shí)驗(yàn)的一個(gè)PHD。標(biāo)題看上去也非常的奪人眼球，拜讀完之后，對(duì)于作者的想法還持有一點(diǎn)疑惑，但是這篇文章很好的闡述了怎么實(shí)現(xiàn)分布式共識(shí)算法，對(duì)于理解Paxos有難度的同學(xué)不妨先去閱讀下這篇論文，能更好的去理解，下面筆者就用純大白話的形式來(lái)一步步說(shuō)明分布式共識(shí)算法。

??lamport大神在其論文中也提及到，所謂的分布式共識(shí)要達(dá)成的目標(biāo)：

達(dá)成一致的結(jié)果一定是由某個(gè)進(jìn)程或者某個(gè)應(yīng)用提出來(lái)的，而不是事先約定的結(jié)果。

最后要達(dá)成一致表明只有一個(gè)值能被選中。

只有已經(jīng)被選中的值才能被其他不參與決策的人(learner)知道。

??如果直接從上面的話來(lái)理解，那么就會(huì)陷入一個(gè)誤區(qū)，或者說(shuō)，看不明一致性的完整過(guò)程，換一個(gè)角度，我們?nèi)绾蝸?lái)保證多個(gè)replica一致性呢，很簡(jiǎn)單，目前最為流行的機(jī)制就是State Machine Replication(aka SMR)。SMR是這么定義的，(1).初始state要相同，(2).對(duì)于同一個(gè)state，給定相同的輸入?yún)?shù)，執(zhí)行相同的操作，輸出結(jié)果是相同的。所以用SMR來(lái)保證一致性的要求就是，相同的狀態(tài)，輸入相同的參數(shù)，執(zhí)行相同的操作。相同的狀態(tài)屬于上一步的結(jié)果，所以約束其實(shí)就是兩個(gè)，相同的參數(shù)(argument)，相同的操作(operation)，說(shuō)到底，paxos那些復(fù)雜的過(guò)程就是為了保證這兩個(gè)約束條件。

??相同的參數(shù)：看起來(lái)簡(jiǎn)單的約束，實(shí)際實(shí)現(xiàn)并非易事，首先在異步網(wǎng)絡(luò)的情況，消息亂序情況就嚴(yán)重干擾了這一約束，你想想看，節(jié)點(diǎn)1先執(zhí)行request n后執(zhí)行m，節(jié)點(diǎn)2先執(zhí)行m后執(zhí)行n，結(jié)果能一樣嗎？那么paxos是如何保證這個(gè)有序性的呢？Paxos在其運(yùn)行過(guò)程，一旦提案p被大多數(shù)的acceptors接受，那么后續(xù)提出的更高編號(hào)的提案都應(yīng)該包含這個(gè)p，看明白了嗎，就是一個(gè)提案未被確認(rèn)執(zhí)行前，所有的acceptors都不允許新的提案(這里的新的提案指的是value不同的提案)發(fā)生，這就間接解決了亂序的問(wèn)題，paxos保證所有的節(jié)點(diǎn)在每一次paxos提案期間只能執(zhí)行一個(gè)提案(同一個(gè)value)，從而來(lái)保證參數(shù)相同，消息有序。

??相同的操作：客戶端發(fā)起狀態(tài)修改必然會(huì)帶著一個(gè)operation的請(qǐng)求(實(shí)際工程中實(shí)現(xiàn)是通過(guò)調(diào)用不同的接口如insert，update，delete等)，那么當(dāng)這個(gè)請(qǐng)求廣播給所有的節(jié)點(diǎn)，那么執(zhí)行自然是相同的操作。問(wèn)題就在于異步網(wǎng)絡(luò)無(wú)法保證可靠性，假如部分節(jié)點(diǎn)網(wǎng)絡(luò)失效，有些沒收到request，自然不會(huì)去執(zhí)行。那么一部分節(jié)點(diǎn)執(zhí)行，一部分節(jié)點(diǎn)不執(zhí)行才是導(dǎo)致操作不同的原因(commit和do-nothing)。體現(xiàn)在paxos就是一旦經(jīng)過(guò)大部分的acceptor同意的提案到被learner學(xué)習(xí)的過(guò)程。工程上常見的實(shí)現(xiàn)方法是用leader來(lái)管理復(fù)制日志來(lái)實(shí)現(xiàn)操作相同的。

??有了上述的認(rèn)知，再來(lái)看一致性，是不是就會(huì)覺得明朗許多，本文標(biāo)題中的另一個(gè)名字是NOPaxos，自然重點(diǎn)就是講解這篇論文了，下面就來(lái)看看論文的作者是如何實(shí)現(xiàn)分布式共識(shí)算法。

??聲明：這里不是純翻譯論文，如果想了解全部的過(guò)程，可以點(diǎn)閱前面的鏈接查看。 傳統(tǒng)的一致性算法如paxos是把上述兩個(gè)約束條件放在應(yīng)用層去實(shí)現(xiàn)，這樣的好處是不依賴于特定的網(wǎng)絡(luò)結(jié)構(gòu)，但是同時(shí)也有一些弊端，首先是一致性的時(shí)間比較長(zhǎng)，性能較低，第二是實(shí)現(xiàn)難度比較大且復(fù)雜。作者另辟蹊徑，如果網(wǎng)絡(luò)層能保證消息有序，那么paxos前面整個(gè)投票過(guò)程就無(wú)需存在了，這樣就把一致性的責(zé)任分?jǐn)傇诹司W(wǎng)絡(luò)層（并非指TCP/IP協(xié)議棧中的網(wǎng)絡(luò)層）和應(yīng)用層。論文主要做了四方面的工作：

定義了一個(gè)有序不可靠的廣播模型(ordered unreliable multicast model，OUM)，能提供強(qiáng)有序的package，但是不保證package一定被接收/處理。

描述了如何實(shí)現(xiàn)這樣一個(gè)OUM模型，提供了三種不同的實(shí)現(xiàn)方案。

介紹應(yīng)用層的NOPaxos協(xié)議，如何在應(yīng)用層協(xié)調(diào)state一致性。

為上述的實(shí)現(xiàn)做實(shí)驗(yàn)驗(yàn)證。

??按照論文本身的說(shuō)法，最簡(jiǎn)單的實(shí)現(xiàn)，就是給每個(gè)消息增加一個(gè)單調(diào)遞增1的序列號(hào)(sequence number)，這樣，節(jié)點(diǎn)在接受到消息的時(shí)候，就能知道每個(gè)消息的先后順序了。除此之外，這一層無(wú)需再提供任何的保證，這樣使得設(shè)計(jì)和實(shí)現(xiàn)都比較簡(jiǎn)單。簡(jiǎn)單的情況下，OUM為每個(gè)request都添加一個(gè)sequence number，應(yīng)用層通過(guò)libOUM調(diào)用接收到這個(gè)request之后，判斷是否是當(dāng)前想要接受的信息。只要sequence number是遞增1，就能判斷出是否亂序或者正常情況。如果出現(xiàn)了跳躍，比如當(dāng)前需要的消息序列號(hào)是n，然后卻接受到了一個(gè)序列號(hào)為m(m > n)的消息，那么上層應(yīng)用就知道n-m中間的消息是丟失，進(jìn)而執(zhí)行其他操作，這樣保證每個(gè)replica接收到的消息是相同的順序。下圖是NOPaxos的一個(gè)整體架構(gòu)：

??每個(gè)客戶端都需要集成兩個(gè)庫(kù)，一個(gè)是用于處理網(wǎng)絡(luò)消息的libOUM，一個(gè)是用于協(xié)調(diào)多個(gè)replica之間操作的NOPaxos。底層網(wǎng)絡(luò)有一個(gè)sequencer，負(fù)責(zé)為每個(gè)消息加上一個(gè)序列號(hào)，為了防止sequencer故障或者失效，需要一個(gè)controller來(lái)進(jìn)行監(jiān)控。總的來(lái)說(shuō)，這個(gè)架構(gòu)總共有三種角色，controller，sequencer，client，其中client有兩種協(xié)議OUM和NOPaxos。下面就一個(gè)個(gè)的來(lái)介紹這些角色分別承擔(dān)的功能和用途。

1. sequencer

??正如前面所說(shuō)，sequencer的功能很簡(jiǎn)單，就是為每個(gè)消息添加一個(gè)序列號(hào)，這個(gè)序列號(hào)必須是單調(diào)遞增1的。論文中，作者提供了三種不同的實(shí)現(xiàn)方式，分別是，基于可編程的交換機(jī)內(nèi)實(shí)現(xiàn)，基于middlebox原型的硬件實(shí)現(xiàn)，純軟件實(shí)現(xiàn)。在介紹這三種實(shí)現(xiàn)之前，先來(lái)考慮這樣一個(gè)網(wǎng)絡(luò)結(jié)構(gòu)，

??上圖是一個(gè)三層胖樹的結(jié)構(gòu)3-level fat-tree，根據(jù)設(shè)計(jì)，所有的客戶端發(fā)出來(lái)的信息都要經(jīng)過(guò)sequencer，如果原本客戶端與replica在同一個(gè)局域網(wǎng)內(nèi)，這樣的設(shè)計(jì)首先會(huì)導(dǎo)致消息路徑增長(zhǎng)，因?yàn)橄⑹紫纫叩絪equencer，再?gòu)膕equencer轉(zhuǎn)發(fā)回來(lái)，明顯消息走過(guò)的路徑就變長(zhǎng)了。所以這里對(duì)于sequencer最合理的位置，就是放在root switch（至于為啥是放在這個(gè)位置會(huì)使得性能最好，可以參考網(wǎng)絡(luò)拓?fù)鋐at-tree的設(shè)計(jì)思路，筆者對(duì)于網(wǎng)絡(luò)拓?fù)錄]有深入研究，這里就不展開）。且論文作者在真實(shí)的環(huán)境下測(cè)試得到，對(duì)于這樣一個(gè)三層胖樹結(jié)構(gòu)的網(wǎng)絡(luò)，88%的情況下，添加一個(gè)序列號(hào)并不會(huì)增加額外的延遲開銷，99%的情況下，只有5us的延遲。因此，增加這樣一個(gè)sequencer并不會(huì)帶來(lái)性能的下降（論文解釋的原因是，不管存不存在這個(gè)sequencer，大部分的package都是需要走到root-switch才能達(dá)到大多數(shù)的group）。sequencer的位置確定了，那么接下來(lái)就是實(shí)現(xiàn)了：

in-switch：理想情況下，如果有一個(gè)可編程的交換機(jī)，那么這個(gè)交換機(jī)可以直接拿來(lái)做sequencer，因?yàn)榻粨Q機(jī)本身就是優(yōu)化設(shè)計(jì)來(lái)作為消息投遞，拆包解包的。然而這些交換機(jī)大部分都是商業(yè)閉源的，市面上比較少見很難買到，作者的實(shí)驗(yàn)是在Intel的Arista7150交換機(jī)上實(shí)現(xiàn)的，基本能達(dá)到0延遲。不僅如此，交換機(jī)本身的計(jì)算模型是非常有限的，且只能用類似于P4的編程語(yǔ)言開發(fā)。

Hardware Middlebox Prototype Sequencing：相比于可編程交換機(jī)來(lái)說(shuō)，基于SDN的OpenFlow交換機(jī)實(shí)現(xiàn)難度降低了很多，可以采用C語(yǔ)言開發(fā)，根據(jù)作者的實(shí)驗(yàn)，這種情況下能99%的case有16us的延遲。

End-host Sequencing：使用普通的終端機(jī)（如果linux server）來(lái)作為sequencer，這種實(shí)現(xiàn)最為簡(jiǎn)單，但是性能最差。畢竟交換機(jī)是數(shù)據(jù)鏈路層或者網(wǎng)絡(luò)層工作的，而終端機(jī)是應(yīng)用層的級(jí)別了，且交換機(jī)本身是專門用于package轉(zhuǎn)發(fā)和處理，性能差距自然很明顯。

2.controller

??有了sequencer自然能實(shí)現(xiàn)消息有序性，但是同時(shí)也引進(jìn)了一個(gè)問(wèn)題，sequencer是一個(gè)單節(jié)點(diǎn)，一下子就使得整個(gè)系統(tǒng)脆弱了很多，雖然說(shuō)發(fā)生故障的概率不高，但是一旦發(fā)生故障，整個(gè)系統(tǒng)不可用不說(shuō)，還可能出錯(cuò)。這個(gè)時(shí)候就需要controller出場(chǎng)了，controller的主要目的是監(jiān)視sequencer，一旦發(fā)現(xiàn)sequencer不可用或者不可達(dá)，則會(huì)選擇一個(gè)替換的sequencer，并更新其路由表。這一過(guò)程引入一個(gè)新的概念，session。每當(dāng)一個(gè)sequencer失效了，需要挑選新的sequencer的時(shí)候，首先重新選定一個(gè)session number，并將信息更新到新的sequencer上。這樣用一個(gè)session的概念就能來(lái)維護(hù)跨sequencer的消息有序了（會(huì)在消息頭上加上一個(gè)二元組 [session-number, sequencer-number] ）。一旦libOUM接收到了一個(gè)更高編號(hào)的session number，則說(shuō)明，舊的session已經(jīng)失效了，但是此時(shí)，libOUM并不知道是否有丟失舊的session中的package，所以不能返回一個(gè)drop-notification，只能返回一個(gè)session-terminated，由上層應(yīng)用去決定改如何處理。至于上層如何處理，后面會(huì)講。這里session number可以采用本地時(shí)間戳，或者將session number持久化到磁盤然后遞增。此外controller的可靠性可以由多個(gè)節(jié)點(diǎn)來(lái)保證，controller選舉sequencer的算法甚至可以直接使用paxos或者raft等，畢竟節(jié)點(diǎn)失效并不是一個(gè)經(jīng)常發(fā)生的事。

??NOPaxos從架構(gòu)圖中可知，屬于一致性協(xié)議最上層的協(xié)議了，通過(guò)調(diào)用底層的libOUM保證消息有序，剩下的如何保證操作一致就是在這個(gè)協(xié)議中實(shí)現(xiàn)的。下面會(huì)分別介紹不同的情況下，NOPaxos是如何執(zhí)行的，首先講明一些概念和變量：

總節(jié)點(diǎn)數(shù)為2f+1，f是最多允許fail的節(jié)點(diǎn)數(shù)，這個(gè)就不必說(shuō)了，paxos也是這么限制的，最少要半數(shù)以上節(jié)點(diǎn)同意提案方可commit。

replica number：每個(gè)replica（每個(gè)副本稱為一個(gè)replica）都有一個(gè)number，

status：每個(gè)replica都有一個(gè)status，normal或者viewchange

view-id：視圖的id，是一個(gè)二元組，[leader-num, session-num]，這的leader-num實(shí)際就是leader的replica number，session-num就是前文中OUM層的session number

session-msg-num：在一個(gè)session內(nèi)，每個(gè)message都有一個(gè)單調(diào)遞增1的序列號(hào)，這個(gè)就是該序列號(hào)

log-slot：log用來(lái)appendrequest操作，log-slot用來(lái)表明這個(gè)操作在日志中的位置。

sync-point：最新的同步點(diǎn)

??系統(tǒng)運(yùn)行只有，協(xié)議的運(yùn)行過(guò)程，只會(huì)出現(xiàn)四種不同的情況，正常的操作，出現(xiàn)消息丟失，發(fā)生視圖轉(zhuǎn)換，系統(tǒng)狀態(tài)同步。下面就分別講解這四種情況下接收到不同消息時(shí)該如何處理，另外關(guān)于leader選舉可以參考viewstamped-replication。

1. Normal Operation

??正常的情況下，客戶端廣播(broadcast)一個(gè)request的消息（消息內(nèi)容為，[request, op, request-id]，其中request-id是用于response的時(shí)候，判斷是哪個(gè)消息，理解為消息的unique key）當(dāng)replica接受到這樣一個(gè)消息的時(shí)候，首先OUM帶過(guò)來(lái)的一個(gè)session-msg-num判斷是不是自己正在等待的消息，如果是，則遞增session-msg-num并將op寫入日志（注意，這里并不執(zhí)行）。如果replica是leader的話，那么就執(zhí)行這個(gè)操作，并寫入日志。然后每個(gè)replica會(huì)回復(fù)客戶端一個(gè)消息（內(nèi)容為，[reply, view-id, log-slot-num, request-id, result]，這里的result只有l(wèi)eader才有回復(fù)，其他為null）?？蛻舳藭?huì)等待f+1個(gè)reply，能match上view-id和log-slot-nums的回復(fù)，其中必須有一個(gè)是leader，如果沒有接收到足夠的回復(fù)，則會(huì)超時(shí)甚至重試。上述是正常的情況下，正常的處理過(guò)程?！締?wèn)題：如果leader提交了，然而client并沒有收到f+1個(gè)reply，這個(gè)時(shí)候怎么辦，沒有任何機(jī)制能反駁leader？raft的機(jī)制就是確認(rèn)replica已經(jīng)寫入了日志才commit的，所以他這里沒寫明我也不明白是為啥】

2. Gap Agrement

??假如此時(shí)libOUM本來(lái)在等待session-msg-num編號(hào)的請(qǐng)求，卻來(lái)了一個(gè)更大的請(qǐng)求，說(shuō)明，中間發(fā)生丟包了。那么此時(shí)，libOUM就會(huì)向上層返回一個(gè)drop-notification，告知session-msg-num丟失了（同一個(gè)session內(nèi)）并且遞增session-msg-num。如果是非leader接收到drop-notification，那么可以向相鄰節(jié)點(diǎn)copy請(qǐng)求，或者不做任何事。如果leader節(jié)點(diǎn)接收到了這樣一個(gè)返回值，則會(huì)在日志中追加一個(gè)NO-OP，并且執(zhí)行下面的操作：

發(fā)送一個(gè)[gap-commit, log-slot]給所有的replica

非leader節(jié)點(diǎn)接收到消息之后，會(huì)在指定的位置插入一個(gè)NO-OP（可能位置已經(jīng)插入了一個(gè)request的op），并且向leader響應(yīng)一個(gè)[gap-commit-rep, log-slot]的消息。leader等待這個(gè)消息，必要的時(shí)候要重試。

??對(duì)于drop操作，客戶端是不需要顯式通知到的，因?yàn)榭梢缘却蛻舳顺瑫r(shí)。當(dāng)然這里在實(shí)際開發(fā)的時(shí)候可以進(jìn)行一些優(yōu)化，比如leader沒有接收到的時(shí)候，也可以向其他的節(jié)點(diǎn)進(jìn)行copy，減少NO-OP的數(shù)目。

3. view change

??前文也說(shuō)到了，NOPaxos這一層有一個(gè)leader的概念，且OUM有一個(gè)session的概念，如果這兩個(gè)一旦有一個(gè)發(fā)生改變，就需要進(jìn)行view change操作了。view change協(xié)議能保證新老視圖中間的狀態(tài)一致性，且能很好的從老的視圖切換到新的視圖。NOPaxos中的視圖變換協(xié)議類似于Viewstamped Replication[42]。算法闡述如下：當(dāng)一個(gè)replica懷疑當(dāng)前的leader掛了，或者接收到了一個(gè)session-terminated，亦或者接收到一個(gè)view-change/view-change-req的消息。此時(shí)他就適當(dāng)?shù)脑黾觢eader-num或者session-num，并且將狀態(tài)status設(shè)置為viewchange。一旦session-num發(fā)生改變，session-msg-num則重置為0。然后廣播一個(gè)消息[view-change-req, view-id]給其他的replica，并且發(fā)送一個(gè)[view-change, view-id, v`, session-msg
-num, log]給新的leader，v`表示上一個(gè)狀態(tài)status為normal的視圖的view-id。當(dāng)一個(gè)replica處于viewchange狀態(tài)的時(shí)候，會(huì)忽略其他消息，除了start-view， view-change，view-change-req。如果超時(shí)，則重新廣播和發(fā)送指定消息給新leader。當(dāng)新leader接收到f+1個(gè)view-change的消息的時(shí)候，則會(huì)執(zhí)行下列操作：從最近最新的view且status為normal的replica合并日志（每個(gè)replica都會(huì)發(fā)送一個(gè)log信息給新的leader）。合并規(guī)則是，如果大家都是no-op，那就是no-op，如果有一個(gè)是request，那就是request。leader拿到新的view-id之后設(shè)置session-msg-num比合并日志大的數(shù)字，然后廣播一個(gè)消息[start-view, view-id, session-msg-num, log]給所有的replica.當(dāng)其他的replica收到了這個(gè)start-view的消息之后，會(huì)更新自己監(jiān)聽的信息，包括view-id，session-msg-num等，并要先同步下日志，如果發(fā)生了日志更新，則會(huì)發(fā)送reply信息給客戶端。最后把自己的status設(shè)置為normal。

4. Synchronization
??定時(shí)同步，這個(gè)屬于優(yōu)化范疇，前文也說(shuō)到，在正常的情況下，leader進(jìn)行commit操作，replica只進(jìn)行日志append，但是隨著系統(tǒng)的運(yùn)行，會(huì)導(dǎo)致log越來(lái)越大，如果leader發(fā)生變更，那么就會(huì)有一個(gè)問(wèn)題，新leader恢復(fù)時(shí)間非常長(zhǎng)。為了在leader變更的時(shí)候，恢復(fù)時(shí)間縮短，NOPaxos決定周期性的進(jìn)行數(shù)據(jù)同步。這一步驟的目的就是確保在sync-point前的所有數(shù)據(jù)，log狀態(tài)都是一致的。小論文并沒有詳細(xì)的指出如何解決這一問(wèn)題，放在了大論文中去講了。

??首先定義正確性是：一個(gè)request被執(zhí)行或者NO-OP這樣的日志被寫進(jìn)f+1個(gè)節(jié)點(diǎn)中，且如果客戶端確保一個(gè)request執(zhí)行成功的標(biāo)記是收到f+1個(gè)回復(fù)，并且我們說(shuō)一個(gè)view v的log是stable的，表明這個(gè)會(huì)成為所有高于view v的視圖的前綴日志。
(1).stable log中的成功操作，在resulting log中也是同樣正確的。
(2).replica總是開始于一個(gè)view中一個(gè)正確的session-msg-num
??值得注意的是，一個(gè)操作（request或者no-op一旦被commit到日志中，將會(huì)永遠(yuǎn)呆著），因?yàn)槿绻趘iew change期間，同時(shí)發(fā)生了操作commit，意味著f+1個(gè)節(jié)點(diǎn)同意了view change，而f+1個(gè)節(jié)點(diǎn)提交了日志，也就說(shuō)明了，至少有一個(gè)節(jié)點(diǎn)同時(shí)執(zhí)行了這兩件事。而且新leader會(huì)跟其他的節(jié)點(diǎn)同步日志，所以如果是大多數(shù)的節(jié)點(diǎn)承認(rèn)的日志會(huì)同步到leader中去。

??后記：閱讀完之后，總覺得有點(diǎn)問(wèn)題，github上有這個(gè)代碼的開源實(shí)現(xiàn)，NOPaxos的源碼，筆者還沒來(lái)得及去看，后續(xù)如果看了會(huì)繼續(xù)開更，希望更多喜歡分布式共識(shí)和分布式一致性的朋友能一起談?wù)撨@個(gè)話題。