自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

聊聊分布式一致性算法協(xié)議 Paxos

開發(fā)
本文我們針對Paxos算法是什么、它的特性以及算法的具體推導(dǎo)過程做了詳細(xì)的闡述。

Google的粗粒度鎖服務(wù)Chubby的設(shè)計開發(fā)者Burrows曾經(jīng)說過:所有一致性協(xié)議本質(zhì)上要么是Paxos要么是其變體。

網(wǎng)上有很多講解Paxos算法的文章,但是質(zhì)量層次不齊。今天筆者帶大家深入聊一下Paxos。

Paxos是什么?

Paxos算法是基于消息傳遞且具有高度容錯特性的一致性算法,是目前公認(rèn)的解決分布式一致性問題最有效的算法之一。

Paxos算法是Lamport宗師提出的一種基于消息傳遞的分布式一致性算法,使其獲得2013年圖靈獎。

自Paxos問世以來就持續(xù)壟斷了分布式一致性算法,Paxos這個名詞幾乎等同于分布式一致性。

Google的很多大型分布式系統(tǒng)都采用了Paxos算法來解決分布式一致性問題,如Chubby、Megastore以及Spanner等。開源的ZooKeeper,以及MySQL 5.7推出的用來取代傳統(tǒng)的主從復(fù)制的MySQL Group Replication等紛紛采用Paxos算法解決分布式一致性問題。

但是它也有兩個明顯的缺點:

  • 難以理解
  • 在工程是實現(xiàn)上比較復(fù)雜。

問題產(chǎn)生的背景

在常見的分布式系統(tǒng)中,總會發(fā)生諸如機器宕機或網(wǎng)絡(luò)異常(包括消息的延遲、丟失、重復(fù)、亂序,還有網(wǎng)絡(luò)分區(qū))等情況。Paxos算法需要解決的問題就是如何在一個可能發(fā)生上述異常的分布式系統(tǒng)中,快速且正確地在集群內(nèi)部對某個數(shù)據(jù)的值達成一致,并且保證不論發(fā)生以上任何異常,都不會破壞整個系統(tǒng)的一致性。

這里某個數(shù)據(jù)的值并不只是狹義上的某個數(shù),它可以是一條日志,也可以是一條命令(command)。根據(jù)應(yīng)用場景不同,某個數(shù)據(jù)的值有不同的含義。

圖片

相關(guān)概念

在Paxos算法中,有三種角色:

  • Proposer (提案者)
  • Acceptor (人大代表)
  • Learners (廣大群眾)

需要注意的是,在具體的算法實現(xiàn)過程中,并不是一個進程只能擔(dān)任其中一種角色,它有可能會同時充當(dāng)多個。比如一個進程既是Proposer又是Acceptor還是Learner。

還有一個很重要的概念叫提案(Proposal)。最終要達成一致的value就在提案里。

這個提案包括什么呢?是僅僅包括一個信息數(shù)值嗎?到底是如何咱們繼續(xù)向下閱讀,目前咱們先認(rèn)為僅僅是一個普普通通的value。

圖片

初次認(rèn)識

Paxos算法過程和我國的立法過程是極其相似的(法律案的提出、法律案的審議、法律案的表決、法律的公布四個階段),所謂的提案就是新頒布法律。

Proposer (提案者)可以提出(propose)提案;Accoptor可以接受(accept)提案;如果某個提案被選定(chosen),那么該提案里的value就被選定了。

回到剛剛說的『對某個數(shù)據(jù)的值達成一致』,指的是Proposer、Acceptor、Learner都認(rèn)為同一個value被選定(chosen)。那么,Proposer、Acceptor、Learner分別在什么情況下才能認(rèn)為某個value被選定呢?

  • Proposer:只要Proposer發(fā)的提案被Acceptor接受(剛開始先認(rèn)為只需要一個Acceptor接受即可,在推導(dǎo)過程中會發(fā)現(xiàn)需要半數(shù)以上的Acceptor同意才行),Proposer就認(rèn)為該提案里的value被選定了。
  • Acceptor:只要Acceptor接受了某個提案,Acceptor就認(rèn)為該提案里的value被選定了。
  • Learner:作為一個學(xué)習(xí)者,Acceptor告訴Learner哪個value被選定,Learner就認(rèn)為那個value被選定。

問題描述

假設(shè)有一組可以提出(propose)value的進程集合(提案者團隊),一個一致性算法需要保證提出的這么多value中,僅僅只有一個相同的value被選定(chosen)。也就是說要么沒有value被提出,只要提出了value并且被選定,那么大家最終學(xué)習(xí)到的value必須是一致的。對于一致性算法,安全性(safaty)要求如下:

  • 只有被提出的value才能被選定。
  • 只有一個value被選定。
  • 如果某個進程認(rèn)為某個value被選定了,那么這個value必須是真的被選定的那個。

Paxos的目標(biāo):保證最終有一個value會被選定,當(dāng)value被選定后,進程最終也能獲取到被選定的value。

俗話說的好,哪里有需求,哪里就會出現(xiàn)糟糕的問題。如果假設(shè)不同角色之間可以通過發(fā)送消息來進行通信,那么:

  • 每個角色以各自任意的速度進行通信執(zhí)行,在這個過程中可能會因為各種原因出錯而導(dǎo)致執(zhí)行停止或重啟。當(dāng)一個value被選定之后,因為故障原因才恢復(fù)正常的角色因為失去了某些重要的信息,導(dǎo)致它們無法確定被選定的值。
  • 消息在傳遞過程中可能出現(xiàn)任意時長的延遲,可能會重復(fù),也可能丟失。但是消息不會被損壞,即消息內(nèi)容不會被篡改(拜占庭將軍問題)。

以上都是可能會遇到的問題,要怎么解決???

推導(dǎo)過程

最簡單的方案——只有一個Acceptor

假設(shè)只有一個Acceptor(可以有多個Proposer),只要Acceptor接受它收到的第一個提案,則該提案被選定,該提案里的value就是被選定的value。這樣就保證只有一個value會被選定。

但是,如果這個唯一的Acceptor宕機了,那么整個系統(tǒng)就無法工作了!

因此,一個Acceptor是不可行的,必須要有多個Acceptor!

圖片

多個Acceptor

當(dāng)有多個Acceptor的時候,如何保證在多個Proposer和多個Acceptor的情況下選定一個value呢?

大家可以自己先進行思考。

首先,我們的最終目標(biāo)是無論有多少Proposer提出提案,有且僅有一個value被選定。

那么,我們可以先定義一個約束:

P1:一個Acceptor必須接受它收到的第一個提案。

但是,這樣又會出現(xiàn)其它的問題:如果每個Proposer所提出的提案value是不同的,并且將提案發(fā)送給不同的Acceptor。根據(jù)P1約束,每個Acceptor都接受它收到的第一個提案,就會出現(xiàn)不同value被選定的情況,出現(xiàn)了不一致。

圖片

剛剛是因為『一個提案只要被一個Acceptor接受,則該提案的value就被選定了』才導(dǎo)致了出現(xiàn)上面不一致的問題。因此,我們需要加一個規(guī)定:

規(guī)定:一個提案被選定需要被半數(shù)以上的Acceptor接受。

一個提案被半數(shù)以上接受,說明『一個Acceptor必須能夠接受不止一個提案!』,不然可能導(dǎo)致最終沒有value被選定。比如上圖的情況。v1、v2、v3都沒有被選定,因為它們都只被一個Acceptor的接受,并沒有被超過半數(shù)以上的Acceptor接受。

最開始將【提案 = value】已經(jīng)無法滿足現(xiàn)在的需求,因為當(dāng)一個Proposer發(fā)送多個提案到一個Acceptor的時候,需要使用一個編號來區(qū)分被提出的順序?,F(xiàn)在【提案=提案編號+value】。

雖然允許多個提案被選定,但必須保證所有被選定的提案都具有相同的value值。否則又會出現(xiàn)不一致。

P2:如果某個value為v的提案被選定了,那么每個編號更高的被選定提案的value必須也是v。

一個提案只有被Acceptor接受才可能被選定,因此我們可以把P2約束改寫成對Acceptor接受的提案的約束P2a。

P2a:如果某個value為v的提案被選定了,那么每個編號更高的被Acceptor接受的提案的value必須也是v。

只要滿足了P2a,就能滿足P2。

但是,考慮如下的情況:以立法過程為背景,假設(shè)總的有5個人大代表(Acceptor)。

人民法院(Proposer2)提出[M1,V1]的提案,人大代表2-5號(半數(shù)以上)均接受了該提案,于是對于人大代表2-5號和人民法院來講,它們都認(rèn)為V1提案是被選定的。此時,人大代表1在辦完其它事務(wù)之后也參與到其中(之前人大代表1沒有收到過任何提案),此時最高人民檢察院(另一個提案者Proposer1)向人大代表1發(fā)送了[M2,V2]的提案(V2≠V1且M2>M1),對于人大代表1來講,這是它收到的第一個提案。根據(jù)P1(一個Acceptor必須接受它收到的第一個提案。),人大代表1必須接受該提案!同時人大代表1認(rèn)為V2被選定。這就出現(xiàn)了兩個問題:

  • 人大代表1認(rèn)為V2被選定,人大代表2-5和人民法院認(rèn)為V1被選定。出現(xiàn)了不一致。
  • V1被選定了,但是編號更高的被人大代表1接受的提案[M2,V2]的value為V2,且V2≠V1。這就跟P2a(如果某個value為v的提案被選定了,那么每個編號更高的被Acceptor接受的提案的value必須也是v)矛盾了。

圖片

所以,我們要對P2a約束進行加強!

P2a是對Acceptor接受的提案約束,但其實提案是Proposer提出來的,所有我們可以對Proposer提出的提案進行約束。得到P2b:

P2b:如果某個value為v的提案被選定了,那么之后任何Proposer提出的編號更高的提案的value必須也是v。

那么,如何確保在某個value為v的提案被選定后,Proposer提出的編號更高的提案的value都是v呢?

只要滿足P2c即可:

P2c:對于任意的N和V,如果提案[N, V]被提出,那么存在一個半數(shù)以上的Acceptor組成的集合S,滿足以下兩個條件中的任意一個:

  • S中每個Acceptor都沒有接受過編號小于N的提案。
  • S中Acceptor接受過的最大編號的提案的value為V。

Proposer生成提案

為了滿足P2b,這里有個比較重要的思想:Proposer生成提案之前,應(yīng)該先去『學(xué)習(xí)』已經(jīng)被選定或者可能被選定的value,然后以該value作為自己提出的提案的value。如果沒有value被選定,Proposer才可以自己決定value的值。這樣才能達成一致。這個學(xué)習(xí)的階段是通過一個『Prepare請求』實現(xiàn)的。

于是我們得到了如下的提案生成算法:

(1) Proposer選擇一個新的提案編號N,然后向某個Acceptor集合(半數(shù)以上)發(fā)送請求,要求該集合中的每個Acceptor做出如下響應(yīng)(response):

  • 向Proposer承諾保證不再接受任何編號小于N的提案。
  • 如果Acceptor已經(jīng)接受過提案,那么就向Proposer響應(yīng)已經(jīng)接受過的編號小于N的最大編號的提案。

我們將該請求稱為編號為N的Prepare請求。

(2) 如果Proposer收到了半數(shù)以上的Acceptor的響應(yīng),那么它就可以生成編號為N,Value為V的提案[N,V]。這里的V是所有的響應(yīng)中編號最大的提案的Value。如果所有的響應(yīng)中都沒有提案,那 么此時V就可以由Proposer自己選擇(一般為當(dāng)前提案)。

生成提案后,Proposer將該提案發(fā)送給半數(shù)以上的Acceptor集合,并期望這些Acceptor能接受該提案。我們稱該請求為Accept請求。(注意:此時接受Accept請求的Acceptor集合不一定是之前響應(yīng)Prepare請求的Acceptor集合)

Acceptor接受提案

Acceptor可以忽略任何請求(包括Prepare請求和Accept請求)而不用擔(dān)心破壞算法的安全性。因此,我們這里要討論的是什么時候Acceptor可以響應(yīng)一個請求。

我們對Acceptor接受提案給出如下約束:

P1a:一個Acceptor只要尚未響應(yīng)過任何編號大于N的Prepare請求,那么他就可以接受這個編號為N的提案。

如果Acceptor收到一個編號為N的Prepare請求,在此之前它已經(jīng)響應(yīng)過編號大于N的Prepare請求。根據(jù)P1a,該Acceptor不可能接受編號為N的提案。因此,該Acceptor可以忽略編號為N的Prepare請求。當(dāng)然,也可以回復(fù)一個error,讓Proposer盡早知道自己的提案不會被接受。

因此,一個Acceptor只需記?。?/p>

  • 已接受的編號最大的提案
  • 已響應(yīng)的請求的最大編號。

Paxos算法描述

經(jīng)過上面的推導(dǎo),我們總結(jié)下Paxos算法的流程。

Paxos算法分為兩個階段。具體如下:

階段一:

  • Proposer選擇一個提案編號N,然后向半數(shù)以上的Acceptor發(fā)送編號為N的Prepare請求。
  • 如果一個Acceptor收到一個編號為N的Prepare請求,且N大于該Acceptor已經(jīng)響應(yīng)過的所有Prepare請求的編號,那么它就會將它已經(jīng)接受過的編號最大的提案(如果有的話) 作為響應(yīng)反饋給Proposer,同時該Acceptor承諾不再接受任何編號小于N的提案。

階段二:

  • 如果Proposer收到半數(shù)以上Acceptor對其發(fā)出的編號為N的Prepare請求的響應(yīng),那么它就會發(fā)送一個針對[N,V]提案的Accept請求給半數(shù)以上的Acceptor(和之前的Acceptor不一定相同)。注意:V就是收到的響應(yīng)中編號最大的提案的value,如果響應(yīng)中不包含任何提案,那么V就由Proposer自己決定。
  • 如果Acceptor收到一個針對編號為N的提案的Accept請求,只要該Acceptor沒有對編號大于N的Prepare請求做出過響應(yīng),它就接受該提案。

圖片

Learner學(xué)習(xí)被選定的value

Learner學(xué)習(xí)(獲取)被選定的value有如下三種方案:

方案一:

Acceptor接受到一個提案,就將該提案發(fā)送給所有Learners.

  • 優(yōu)點:Learner能夠快速獲取被選定的value
  • 缺點:通信次數(shù)為M*N(M為提案數(shù),N為Learner數(shù))

方案二

Acceptor接受一個提案,就將提案發(fā)送給主Learner,主Learner再通知其它Learner

  • 優(yōu)點:通信次數(shù)減少(M+N-1)(M為提案數(shù),N為Learner數(shù),M個提案發(fā)送給主Learner,然后主Learner通知N-1個Learner)
  • 缺點:單點故障問題(主Learner可能出現(xiàn)故障)

方案三

Acceptor接受一個提案,就將提案發(fā)送給Learner團,Learner團再通知其它Learner

  • 優(yōu)點:解決了方案二單點故障問題,可靠性好
  • 缺點:實現(xiàn)復(fù)雜,網(wǎng)絡(luò)通信復(fù)雜度高

如何保證Paxos算法的活性

通過選取主Proposer,就可以保證Paxos算法的活性。通過選取主Proposer,并規(guī)定只有主Proposer才能提出議案。這樣一來只要主Proposer和過半的Acceptor能夠正常進行網(wǎng)絡(luò)通信,那么但凡主Proposer提出一個編號更高的提案,該提案終將會被批準(zhǔn),這樣通過選擇一個主Proposer,整套Paxos算法就能夠保持活性。至此,我們得到一個既能保證安全性,又能保證活性的分布式一致性算法——Paxos算法。

圖片

總結(jié)

到此,我們針對Paxos算法是什么、它的特性以及算法的具體推導(dǎo)過程做了詳細(xì)的闡述。Paxos算法是現(xiàn)在很多一致性算法的變體,非常值得我們學(xué)習(xí)。

責(zé)任編輯:趙寧寧 來源: 碼猿技術(shù)專欄
相關(guān)推薦

2024-11-28 10:56:55

2020-03-16 11:55:28

PaxosRaft協(xié)議

2019-10-11 23:27:19

分布式一致性算法開發(fā)

2020-10-28 11:15:24

EPaxos分布式性算法

2020-05-11 10:30:57

2PC分布式協(xié)議

2019-09-05 08:43:34

微服務(wù)分布式一致性數(shù)據(jù)共享

2021-11-22 16:30:30

分布式一致性分布式系統(tǒng)

2024-05-27 10:42:55

2017-09-21 10:59:36

分布式系統(tǒng)線性一致性測試

2021-07-28 08:39:25

分布式架構(gòu)系統(tǒng)

2021-06-03 15:27:31

RaftSOFAJRaft

2022-11-10 07:49:09

hash算法代碼

2020-05-29 14:46:23

3PC協(xié)議分布式系統(tǒng)

2021-06-06 12:45:41

分布式CAPBASE

2017-09-22 12:08:01

數(shù)據(jù)庫分布式系統(tǒng)互聯(lián)網(wǎng)

2018-04-10 16:24:03

算法分布式一致性

2018-03-13 08:20:48

區(qū)塊鏈數(shù)據(jù)安全

2023-11-06 09:06:54

分布式一致性數(shù)據(jù)

2021-06-16 08:33:02

分布式事務(wù)ACID

2020-05-07 11:58:07

分布式系統(tǒng)架構(gòu)
點贊
收藏

51CTO技術(shù)棧公眾號