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

淺談分布式系統(tǒng)一致性之3PC協(xié)議

網(wǎng)絡(luò) 網(wǎng)絡(luò)管理 分布式
分布式系統(tǒng)一致性專(zhuān)題本期該寫(xiě) 3PC 協(xié)議了,上周太忙沒(méi)有時(shí)間更新,就拿了之前的舊文章做了一些調(diào)整重發(fā)了一下,還望各位讀者海涵。后面大約還有3期:Paxos 協(xié)議、Raft 協(xié)議等,先預(yù)熱一下。

 

本文轉(zhuǎn)載自微信公眾號(hào)「 后端技術(shù)指南針」,轉(zhuǎn)載本文請(qǐng)聯(lián)系 后端技術(shù)指南針公眾號(hào)。

 一.寫(xiě)在前面

分布式系統(tǒng)一致性專(zhuān)題本期該寫(xiě) 3PC 協(xié)議了,上周太忙沒(méi)有時(shí)間更新,就拿了之前的舊文章做了一些調(diào)整重發(fā)了一下,還望各位讀者海涵。后面大約還有3期:Paxos 協(xié)議、Raft 協(xié)議等,先預(yù)熱一下。溫馨提示:本篇文章并不會(huì)枯燥,換了個(gè)畫(huà)圖工具,對(duì)于我這種建筑專(zhuān)業(yè)出身的IT狗來(lái)說(shuō),畫(huà)圖簡(jiǎn)直是最開(kāi)心的事情了,所以放心看吧!

[[328175]]

 

圖(網(wǎng)絡(luò))|獵戶座大星云

二.3PC的出現(xiàn)

之前文章中提到了 2PC 協(xié)議存在的協(xié)調(diào)者單點(diǎn)、參與者阻塞超時(shí)、網(wǎng)絡(luò)分區(qū)、容錯(cuò)性等問(wèn)題,這些在某些程度上是做優(yōu)化和調(diào)整的,并不是致命問(wèn)題。我們對(duì) 2PC 協(xié)議的異常情況做了拆解,但是那是個(gè)m*n的組合問(wèn)題,我們盡量去分析主要矛盾,于是發(fā)現(xiàn)在協(xié)調(diào)者和唯一接收指令的參與者都出現(xiàn)不可恢復(fù)宕機(jī)時(shí),即使后面選舉了新的協(xié)調(diào)者,仍然可能出現(xiàn)數(shù)據(jù)的不一致性。3PC 的出現(xiàn)可能是多種因素促成的。但是基本上可以確定 3PC 將對(duì) 2PC 存在的問(wèn)題進(jìn)行修正和優(yōu)化,但是這樣并不意味著 3PC 不會(huì)引入新的問(wèn)題。本文將從 3PC 的協(xié)議過(guò)程來(lái)闡述這兩大塊內(nèi)容:

 

三. 3PC協(xié)議的基本過(guò)程

3PC協(xié)議 Three-Phase-Commit 又稱(chēng)三階段提交協(xié)議,相比 2PC 協(xié)議增加了一個(gè)階段,因此我們普遍把 3PC 協(xié)議看作是 2PC 協(xié)議的改進(jìn)版本。3PC 協(xié)議將 2PC 協(xié)議的準(zhǔn)備階段一分為二,從而形成了三個(gè)階段:

 

協(xié)調(diào)者和參與者等待超時(shí)情況單獨(dú)說(shuō),先看正常情況的基本過(guò)程,要不然容易混淆。

3.1 CanCommit階段

在2PC準(zhǔn)備階段中,協(xié)調(diào)者向參與者發(fā)送指令后,參與者如果具備執(zhí)行條件,則獲取鎖并執(zhí)行動(dòng)作,只不過(guò)未真正提交,可以認(rèn)為參與者就差臨門(mén)一腳了,還得等協(xié)調(diào)者信號(hào)。如果是 commit 信號(hào)那還好,如果是 rollback 信號(hào),那么對(duì)于一些本地執(zhí)行了動(dòng)作的參與者來(lái)說(shuō)白白浪費(fèi)了,所以從這個(gè)角度來(lái)說(shuō),2PC 有點(diǎn)激進(jìn)了,但是這么做也是有原因的,在復(fù)雜的網(wǎng)絡(luò)環(huán)境中多一輪交互意味著性能的損耗。3PC來(lái)說(shuō)更加合理,先由協(xié)調(diào)者向參與者發(fā)送詢問(wèn)信號(hào),兄弟們有檔期嗎??然后開(kāi)始收集反饋,相比來(lái)說(shuō)更加輕量。這個(gè)階段參與者并不真實(shí)獲取鎖占用資源,只是對(duì)自身執(zhí)行事務(wù)狀態(tài)的檢查,查看是否具備執(zhí)行事務(wù)的條件,進(jìn)而回復(fù)詢問(wèn)。

根據(jù)參與者對(duì)詢問(wèn)的反饋,在 CanCommit 階段可能出現(xiàn)的兩情況:

A.所有參與者均Ready的場(chǎng)景

 

圖:詢問(wèn)階段所有參與者均具備執(zhí)行事務(wù)條件

B.存在參與者不OK的場(chǎng)景

 

圖:詢問(wèn)階段存在不具備條件的參與者

3.2 PreCommit階段

第二個(gè)階段的具體動(dòng)作取決于第一個(gè)階段的結(jié)果,因此可以分為兩種情況:

  • CanCommit階段一致通過(guò)

在第一階段所有參與者都 Ready,那么協(xié)調(diào)者就會(huì)向參與者發(fā)送本地執(zhí)行的相關(guān)指令,這部分和 2PC 的第一階段非常相似,參與者收到指令后進(jìn)行本地事務(wù)執(zhí)行,并記錄日志,并且對(duì)處理結(jié)果反饋到協(xié)調(diào)者,來(lái)做決策。過(guò)程中參與者可能成功或者失敗,出現(xiàn)了兩種情況:

圖:PreCommit階段參與者均反饋成功


圖:PreCommit階段參與者中存在失敗實(shí)例

 

CanCommit階段存在分歧

在第一階段如果存在參與者不 Ready 的情況,那么協(xié)調(diào)者就會(huì)發(fā)送信號(hào)給所有參與者,告知本次事務(wù)取消了,該干啥干啥吧,對(duì)參與者來(lái)說(shuō)損失并不大,因?yàn)楸举|(zhì)上參與者并沒(méi)有做什么事情。

 

3.3 DoCommit階段

這是 3PC 的第三個(gè)階段和2PC的第二個(gè)階段類(lèi)似,同樣的 DoCommit 執(zhí)行具體動(dòng)作取決于第二階段 PreCommit 的結(jié)果,因此仍然分為兩種情況:

  • PreCommit階段一致通過(guò)

在 PreCommit 之后參與者全部完成本地事務(wù)執(zhí)行但是沒(méi)有提交,并且都給協(xié)調(diào)者 ACK 回復(fù),這時(shí)協(xié)調(diào)者認(rèn)為萬(wàn)事俱備只欠東風(fēng)了,在 DoCommit 階段協(xié)調(diào)者向參與者發(fā)送提交指令,參與者收到之后開(kāi)始執(zhí)行本地提交,并反饋結(jié)果,最終完成這次事務(wù),Cool!

 

  • PreCommit階段存在分歧

協(xié)調(diào)者在第二個(gè)階段 PreCommit 收到參與者的反饋后,發(fā)現(xiàn)存在部分參與者無(wú)法執(zhí)行事務(wù)的情況,這時(shí)就決定告訴其他參與者本地回滾,釋放資源,取消本次事務(wù)。

 

四. 3PC中的超時(shí)策略

我們前面提到 3PC 要解決 2PC 的參與者阻塞超時(shí)問(wèn)題,在2PC中參與者比較癡情,協(xié)調(diào)者不給信號(hào)會(huì)長(zhǎng)時(shí)間阻塞,不釋放資源,這樣別人也沒(méi)法處理其他事情,確實(shí)不太好,看來(lái) 2PC 還是太依賴協(xié)調(diào)者了。3PC 認(rèn)為網(wǎng)絡(luò)超時(shí)是普遍發(fā)生的情況,如果參與者在一種大概率確定的狀態(tài)下執(zhí)行一些動(dòng)作也是被允許的,將在外軍令有所不受。3PC 的超時(shí)處理可能發(fā)生在 PreCommit 和 DoCommit 階段,來(lái)看個(gè)圖:

 

參與者等待 PreCommit 超時(shí)

協(xié)調(diào)者和參與者之間可能存在較大的網(wǎng)絡(luò)延時(shí),或者協(xié)調(diào)者出現(xiàn)故障,或者出現(xiàn)網(wǎng)絡(luò)分區(qū)等情況,參與者并不會(huì)傻等,在超過(guò)設(shè)定時(shí)間之后,參與者就繼續(xù)做之前的事情了,因?yàn)楹孟癖淮蟾瑛澚?,只能該干啥干啥,這也是正確的決策。

參與者等待 DoCommit 超時(shí)

在 CanCommit 和 PreCommit 之后,參與者認(rèn)為大家都對(duì)齊了都是棒棒的,如果參與者在設(shè)定時(shí)間內(nèi)并沒(méi)有收到協(xié)調(diào)者的 DoCommit 指令,那么就本地執(zhí)行提交完成這次事務(wù),因?yàn)閰⑴c者揣測(cè)大哥的意思大概率也是讓我們提交,干等著也不是辦法,回滾可能和大家不一樣,抉擇之下參與者選擇提交事務(wù)。

協(xié)調(diào)者等待反饋超時(shí)

3PC協(xié)調(diào)者的等待超時(shí)處理和2PC基本上是一樣的,無(wú)論在哪個(gè)階段超時(shí)都認(rèn)為不具備條件,進(jìn)行 abort 或者 rollback 操作,這個(gè)非常好理解。

可以看到3PC協(xié)議中參與者不再過(guò)度依賴協(xié)調(diào)者的指令信號(hào),而是有了自己的相對(duì)獨(dú)立性,可以根據(jù)當(dāng)前所處的狀態(tài)來(lái)進(jìn)行自我決策。避免了2PC中的阻塞等待帶來(lái)的資源浪費(fèi)情況,確實(shí)是個(gè)不錯(cuò)的優(yōu)化,但是我們并不能完全保證這種優(yōu)化就都是完全正確的呀!換句話說(shuō)3PC解決了2PC的bug,但是不代表3PC沒(méi)有引入新的bug。

五. 3PC協(xié)議的一些分析

前面我們說(shuō)到3PC協(xié)議的一個(gè)重要作用就是要對(duì)2PC協(xié)議的改進(jìn)和優(yōu)化,從上面的過(guò)程分析可知確實(shí)做了一些優(yōu)化,但是仍然不可避免出現(xiàn)了新的問(wèn)題。

5.1 3PC的數(shù)據(jù)不一致問(wèn)題

2PC協(xié)議在某些場(chǎng)景下數(shù)據(jù)不一致問(wèn)題,那么3PC有沒(méi)有這種問(wèn)題呢?答案是有,根源是新加的參與者超時(shí)機(jī)制。比如參與者A因?yàn)樽陨砭W(wǎng)絡(luò)問(wèn)題,在設(shè)定時(shí)間內(nèi)未收到協(xié)調(diào)者的信號(hào),這時(shí)參與者A基于之前的狀態(tài)執(zhí)行了Commit操作,提交了事務(wù),這種情況確實(shí)會(huì)發(fā)生,根據(jù)真實(shí)的協(xié)調(diào)者信號(hào)是commit還是rollback會(huì)出現(xiàn)不同的結(jié)果。

如果協(xié)調(diào)者發(fā)送的是Commit指令,就和參與者A獨(dú)自決策結(jié)果一致,沒(méi)啥問(wèn)題。如果協(xié)調(diào)者在DoCommit階段發(fā)送的是rollback指令,那么超時(shí)的參與者A由于執(zhí)行了本地事務(wù)提交,從而和其他收到指令執(zhí)行rollback的參與者的數(shù)據(jù)不一致。

 

5.2 決策狀態(tài)的對(duì)齊

我們知道2PC協(xié)議的決策結(jié)果初始階段只有決策者知道,只有在它發(fā)送了決策解決才有參與者知道,這樣就存在決策結(jié)果丟失的情況。假如協(xié)調(diào)者掛掉,新協(xié)調(diào)者可以咨詢所有的參與者來(lái)確定決策狀態(tài),根據(jù)所有參與者的情況來(lái)確定,但是萬(wàn)一真理掌握在少數(shù)人手中呢?

極端情況:

假如有10個(gè)參與者,9個(gè)都是正常的,1個(gè)狀態(tài)未知(先叫做A吧),10個(gè)參與者都向協(xié)調(diào)者發(fā)送了反饋,如果A反饋的是Not Ready信號(hào),其他9個(gè)都是Ready信號(hào)。協(xié)調(diào)者匯總結(jié)果決策出不具備執(zhí)行條件,開(kāi)始向所有參與者發(fā)送rollback,恰好第一個(gè)收到信號(hào)的是A機(jī)器,協(xié)調(diào)者掛了,A收到信號(hào)后也掛了。新的協(xié)調(diào)者詢問(wèn)了其余9個(gè)都是OK,新的協(xié)調(diào)者就認(rèn)為具備條件了從而發(fā)送Commit信號(hào),這樣就出現(xiàn)了不一致。

腦洞大開(kāi):

這個(gè)過(guò)程和清宮劇中皇帝立儲(chǔ)很像嘛,皇帝把結(jié)果掛在朝堂的牌匾之上,假定詔書(shū)消失了且皇帝掛了,那么結(jié)果就不得而知了,智囊團(tuán)在沒(méi)有私心的前提下就需要考察所有的侯選人的情況來(lái)確定,這樣就可能出現(xiàn)不一致。

決策透明化:

在3PC中仍然存在只有1臺(tái)機(jī)器收到指令然后掛掉的情況,但是如果出現(xiàn)在前置階段,對(duì)整個(gè)結(jié)果是沒(méi)有影響的,因?yàn)闀?huì)被取消并且參與者并沒(méi)有本地執(zhí)行。

現(xiàn)在看3PC的思想是把做重大動(dòng)作時(shí)的決策結(jié)果透明化統(tǒng)一化,產(chǎn)生的影響也就非常小了,因此PreCommit階段的狀態(tài)是明確的。

我們需要把決策結(jié)果透明化,讓所有參與者都知道決策結(jié)果,3PC的PreCommit階段對(duì)齊了結(jié)果,只要有1臺(tái)還活著,整個(gè)事務(wù)的狀態(tài)就是確定的,畢竟所有參與者全掛的情況概率非常低。

 

六.小結(jié)

3PC協(xié)議是對(duì)2PC協(xié)議的優(yōu)化和改進(jìn),通過(guò)將2PC的準(zhǔn)備階段一分為二:CanCommit和PreCommit,整個(gè)過(guò)程中下一階段的流轉(zhuǎn)要取決于上一個(gè)階段的結(jié)果,流轉(zhuǎn)簡(jiǎn)圖:

 

經(jīng)過(guò)CanCommit和PreCommit階段后,參與者之間對(duì)齊并保留了決策結(jié)果,避免2PC協(xié)議極端情況決策結(jié)果的錯(cuò)誤缺失,是個(gè)比較好的做法。

2PC協(xié)議只有協(xié)調(diào)者有超時(shí)機(jī)制,3PC協(xié)議對(duì)參與者也引入了超時(shí)機(jī)制,在不同的階段進(jìn)行不同的超時(shí)處理,但是由于網(wǎng)絡(luò)波動(dòng)和網(wǎng)絡(luò)分區(qū)存在讓參與者的超時(shí)處理帶來(lái)新的不確定性,甚至可能出現(xiàn)數(shù)據(jù)不一致。

3PC協(xié)議增加一輪詢問(wèn)階段所以整個(gè)交互過(guò)程比2PC更長(zhǎng)了,性能相比2PC是會(huì)有一些下降的,但是3PC協(xié)議對(duì)于網(wǎng)絡(luò)分區(qū)等情況也并沒(méi)有處理地很好。

 

總體來(lái)說(shuō),3PC相比2PC做了很多改進(jìn)有一定的效果,但是仍然存在數(shù)據(jù)不一致問(wèn)題,還需繼續(xù)努力。

責(zé)任編輯:武曉燕 來(lái)源: 后端技術(shù)指南針
相關(guān)推薦

2020-05-11 10:30:57

2PC分布式協(xié)議

2023-06-12 08:27:23

PaxosBASECAP

2017-09-22 12:08:01

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

2021-06-03 15:27:31

RaftSOFAJRaft

2025-03-14 08:00:00

分布式系統(tǒng)服務(wù)器一致性

2019-10-09 08:41:49

XA2PC3PC

2022-06-07 12:08:10

Paxos算法

2017-04-06 11:59:19

分布式服務(wù)化系統(tǒng)

2019-10-11 23:27:19

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

2017-09-21 10:59:36

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

2021-07-28 08:39:25

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

2019-09-05 08:43:34

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

2021-11-22 16:30:30

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

2024-11-28 10:56:55

2021-10-27 10:55:29

分布式

2018-03-19 09:50:50

分布式存儲(chǔ)系統(tǒng)

2020-05-07 11:58:07

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

2023-07-25 09:52:00

本地事務(wù)宕機(jī)

2021-06-06 12:45:41

分布式CAPBASE

2020-10-28 11:15:24

EPaxos分布式性算法
點(diǎn)贊
收藏

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