zookeeper paxos是什么

本篇內容主要講解“zookeeper paxos是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“zookeeper paxos是什么”吧!

先講一個故事。

從前，在國王Leslie Lamport的統治下，有個黑暗的希臘城邦叫paxos。城邦里有3類人，

• 決策者

• 提議者

• 群眾

雖然這是一個黑暗的城邦但是很民主，按照議會民主制的政治模式制訂法律，群眾有什么建議和意見都可以寫提案交給提議者，提議者會把提案交給決策者來決策，決策者有奇數個，為什么要奇數個？很簡單因為決策的方式很無腦，少數服從多數。

最后決策者把剛出爐的決策昭告天下，群眾得知決策結果。

等一下，那哪里黑暗呢？問題就出在“提議者會把提案交給決策者來決策”，那么多提案決策者先決策誰的？誰給的錢多就決策誰的。

那這樣會有幾個問題，決策者那么多，怎么保證最后決策的是同一個提案，以及怎么保證拿到所有提議者中最高的報價。

聰明又貪婪的決策者想到了一個辦法：分兩階段報價

第一階段

1. 決策者接受所有比他當前持有報價高的報價，且不會通知之前報價的人

2. 提議者給所有決策者報價，若有人比自己報價高就加價，有半數以上決策者接受自己報價就停止報價。

第一階段結束的狀態

每個提議者都覺得有半數以上的大佬接受了自己的提案，很開心。而決策者集團此刻的狀態是一致的，半數以上同意的提案只有一個，這個就是報價最高的（因為高的總是可以覆蓋低的），具體是誰提的who care，一致就行。

第二階段

提議者去找收過自己錢的大佬簽合同，這里有3種情況：

1. 大佬都收了別人更高的價，回去拿錢繼續賄賂，回到第一階段重新升級;

2. 大佬收到的最高報價是自己的，美滋滋，半數以上成功簽合同，提案成功;

3. 提議者回去拿錢回來繼續賄賂的時候發現合同已經被簽了且半數以上都簽了這個提案，不干了，趕快把自己的提案換成已經簽了的提案，再去提給所有大佬，看看能不能分一杯羹遇見還沒簽的大佬。

第二階段結束的狀態

所有提議者手頭的提案都是一樣的，因為有“趕快把自己的提案換成已經簽了的提案”這一步;決策者集團所有成員最終接受的提案是一樣的。

好的目的已經達到了，把這個提案昭告天下，讓所有群眾知道這件事。

故事說完了，用正確的姿勢再簡單介紹下paxos

paxos是什么？

Paxos是一種分布式一致性算法，用于解決分布式系統中一致性問題，可以說是分布式一致性的奠基石，基本所有的一致性算法都是基于它做的改造。

至于paxos的內容，上面的故事其實已經講得很清楚了，下面我再用專業的詞“解釋”一遍。

分布式系統中的節點通信存在兩種模型：共享內存（Shared memory）和消息傳遞（Messages passing）。

paxos作為基于消息傳遞通信模型的分布式系統，不可避免的會發生以下錯誤：進程可能會慢、被殺死或者重啟，消息可能會延遲、丟失、重復，在基礎 Paxos 場景中，先不考慮可能出現消息篡改即拜占庭錯誤的情況。

Paxos算法解決的問題是在一個可能發生上述異常的分布式系統中如何就某個值達成一致，保證不論發生以上任何異常，都不會破壞決議的一致性。一個典型的場景是，在一個分布式數據庫系統中，如果各節點的初始狀態一致，每個節點都執行相同的操作序列，那么他們最后能得到一個一致的狀態。

為保證每個節點執行相同的命令序列，需要在每一條指令上執行一個“一致性算法”以保證每個節點看到的指令一致。一個通用的一致性算法可以應用在許多場景中，是分布式計算中的重要問題。

在paxos算法中，分為4種角色：

• Acceptor：決策者

• Proposer ：提議者

• Client：產生議題者（群眾）

• Learner：最終決策學習者（群眾）

階段一：

1. Proposer向半數以上的Acceptor發送Prepare請求并附上編號N。

2. 若Acceptor收到一個編號為N的Prepare請求，且N大于該Acceptor已經響應過的所有Prepare請求的編號，那么它就會將它已經接受過的編號最大的提案（如果有的話）作為響應反饋給Proposer，同時該Acceptor承諾不再接受任何編號小于N的提案。

3. Proposer若沒有得到半數以上Acceptor的響應，則編號+1繼續發起請求。

階段二：

1. 如果Proposer收到半數以上Acceptor對其發出的編號為N的Prepare請求的響應，那么它就會發送一個[N,提案]Accept請求給半數以上的Acceptor。

2. 如果Acceptor收到一個針對編號為N的提案的Accept請求，只要該Acceptor沒有對編號大于N的Prepare請求做出過響應，它就接受該提案

另外再提一下，在一個Paxos過程只批準一個value，只有被prepare的value且被多數Acceptor接受才能被批準，被批準的value才能被learner。

看故事的時候不知道大家有沒有疑問，我是有的

決策者Acceptor為什么要多個？

若只有一個acceptor多個proposer，acceptor可以選任意一個提案，很美好，但是有單點問題。

為什么要用“半數以上通過”這個辦法來決策？

一個集合不可能同時存在兩個半數以上的子集，過半的思想保證提交的value在同一時刻在分布式系統中是唯一的一致的。

這種提交方式不管proposer接受到的消息是接受了誰的提議過半，只保證是有提議過半了的。然后再在第二階段確定這個過半了的提議，讓所有節點知道這件事。因此算法如果能保證value被半數acceptor接受，則意味這此時被認定的value是唯一的。

為什么acceptor要接受多個提案？

如果acceptor只能夠接受一個提案，則可能發生所有proposer提出的提案都無法達到多數，決策者接收一個就結束了，狀態無法一致。

當Proposer有很多個的時候，會有什么問題？

很難有一個proposer收到半數以上的回復，進而不斷地執行第一階段的協議，決策收斂速度慢，很久都不能做出一個決策。

提案為什么要帶上編號（即故事中用來賄賂的錢）？

帶上編號是為了決策者可以在自身接受到的提案的對比中做出最終的唯一決策。

試想如果按照提案到達時間對比提案，且不說這樣就變成了只接收一個第一到達的提案，還可能因為網絡原因每個決策者接受到的提案的先后順序不一樣，涼涼。

接著上面的問題，那如果把所有決策者收到的提案匯集起來選出個時間最早的呢？

把提案匯集，這時候肯定需要一個master來做判斷，大家有沒發現這個master好像就變成了propser，它拿到最早的提案，交給決策者...

其實，這就演變成了paxos的變種協議。

到此，相信大家對“zookeeper paxos是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！