zookeeperpaxos算法及zab協(xié)議、chubby技術架構解析sean第三課

性、持久性2P=TwoPhase 二段提交（RDBMS經(jīng)常就這種機制，保證強一致性3P=ThreePhase 2P-1：提交事務請求（投票階段理

undoredoundoredo2P-2：執(zhí)行事務提交（commit、

3P-13P-23P-3：提交（commit、CAP理論（分布式系統(tǒng)遵循的理論（Consistency（AvailabilityAP(C)：放棄強一致性，用最終一致性來保證。BASE理availablestate最終一致性：datareplications經(jīng)過一段時間達到一致性。Paxos算拜占庭將軍拜占庭就是5~15世紀的東羅馬，拜占庭即現(xiàn)在土耳其的 以想象，拜占庭有許多分支，駐扎在敵人城外，每一分支由各自的將軍指揮。將軍們智一行動計劃的制訂與。如果這11位將軍中有 呢?假設有9位忠誠的將軍，5位判斷進攻，4位判斷撤退，還有2個 判斷撤退雖然結果是錯誤的撤退但這種情況完全是允許的因為這111.11同時進攻（議案、決議、同時撤退（議案、決議在Paxos算法面前，其他（包括2P、3P）都是渣渣，都是殘次品。Chubby的作者MikeBurrows proposer設定1：如果Acceptor沒有接受議案，那么他必須接受第一個議3：接受編號大的議案，如果小于之前接受議案編號，那么不接受設定4：議案有2種(提交的議案，批準的議案Prepare階段（決議提交ProposerVPrepareAcceptor。Prepare請求內(nèi)容KAcceptorPrepareKPrepareAcceptorPrepareOKProposer，代表Acceptor必須接受收到的第一個議案（1）如：MaxNK<MaxNrejecterrorProposer如果K>=MaxN那么檢查之前是否有批準的議案如果沒有則用OK來回復Proposer，KAccept階段（批準階段Proposer收到過半Acceptor發(fā)來的回復，回復都是OK，且沒有附帶任何批準過的議ProposerK和議案內(nèi)V一起提交（<K,V>這種數(shù)據(jù)形式）Proposer收到過半Acceptor發(fā)來的回復，回復都是OK，且附帶批準過的議案編號和議案內(nèi)容（<pok，議案編號，議案內(nèi)容Proposer找到所有回復中超過半數(shù)的那個（假設為<pok，AcceptNx，AcceptVx>）作為提交批準請求（請求為<K，AcceptVx>）Proposer沒有收到過半Acceptor發(fā)來的回復，則修改議案編號K為Kx，并將編號重Acceptors（Prepare階段的過程）Acceptor收到Proposer發(fā)來的AcceptK<MaxN則不回應或者rejectAcceptorProposerAcceptK>=MaxN則批準該議案，并設置手里批準的議案為<K，接受議案的編號，接受議案的內(nèi)容>Proposer。ProposerAccept（代表議案被批準LeanerPrepare階段。Paxosproposer：1，acceptor：1，2，3（決策者（ok1（Accepted來，避免遺忘；又由于之前已經(jīng)接受參謀1221 時間proposer：1，acceptor：1，2，3（決策者 （ok （ok1，11（Accepted1，由于因此讓通信兵帶信回去，內(nèi)容為（Rejected，22，22（Accepted將軍1收到參謀1的提議，由于（編號3）大于之前保存的（編號1，因此把（編號3）保存下來；由于將軍1已經(jīng)接受參謀1前一次的提議，因此讓通信兵帶信回去，內(nèi)容為（11將軍2收到參謀1的提議，由于（編號3）大于之前保存的（編號2，因此把（編號3）保存下來；由于將軍2