詳解分布式基礎(chǔ)之一致性協(xié)議、2PC和3PC

在分布式系統(tǒng)中，每一個(gè)機(jī)器節(jié)點(diǎn)雖然都能明確的知道自己在事務(wù)操作中的結(jié)果是成功或失敗，但無法直接獲取其他節(jié)點(diǎn)的操作結(jié)果。因此在分布式環(huán)境中，為了保持事務(wù)的ACID特性，就需要增加一個(gè)“協(xié)調(diào)者”來管理其他節(jié)點(diǎn)(“參與者”)事務(wù)的提交和回滾。基于這個(gè)思想，衍生出二階段提交和三階段提交兩種協(xié)議。

一、一致性問題

一致性問題：一致性問題就是相互獨(dú)立的節(jié)點(diǎn)之間如何達(dá)成一項(xiàng)決議的問題。分布式系統(tǒng)中，進(jìn)行數(shù)據(jù)庫事務(wù)提交(commit transaction)、Leader選舉、序列號(hào)生成等都會(huì)遇到一致性問題。分布式滿足一致性場(chǎng)景：

假設(shè)一個(gè)具有N個(gè)節(jié)點(diǎn)的分布式系統(tǒng)，當(dāng)其滿足以下條件時(shí)，我們說這個(gè)系統(tǒng)滿足一致性：(1)全認(rèn)同(agreement): 所有N個(gè)節(jié)點(diǎn)都認(rèn)同一個(gè)結(jié)果(2)值合法(validity): 該結(jié)果必須由N個(gè)節(jié)點(diǎn)中的節(jié)點(diǎn)提出(3)可結(jié)束(termination): 決議過程在一定時(shí)間內(nèi)結(jié)束，不會(huì)無休止地進(jìn)行下去.

分布式面臨的問題：

(1)消息傳遞異步無序(asynchronous): 現(xiàn)實(shí)網(wǎng)絡(luò)不是一個(gè)可靠的信道，存在消息延時(shí)、丟失，節(jié)點(diǎn)間消息傳遞做不到同步有序(synchronous)(2)節(jié)點(diǎn)宕機(jī)(fail-stop): 節(jié)點(diǎn)持續(xù)宕機(jī)，不會(huì)恢復(fù)(3)節(jié)點(diǎn)宕機(jī)恢復(fù)(fail-recover): 節(jié)點(diǎn)宕機(jī)一段時(shí)間后恢復(fù)，在分布式系統(tǒng)中最常見(4)網(wǎng)絡(luò)分化(network partition): 網(wǎng)絡(luò)鏈路出現(xiàn)問題，將N個(gè)節(jié)點(diǎn)隔離成多個(gè)部分(5)拜占庭將軍問題(byzantine failure): 節(jié)點(diǎn)或宕機(jī)或邏輯失敗，甚至不按套路出牌拋出干擾決議的信息

一致性還具備兩個(gè)屬性，一個(gè)是強(qiáng)一致(safety)，它要求所有節(jié)點(diǎn)狀態(tài)一致、共進(jìn)退;一個(gè)是可用(liveness)，它要求分布式系統(tǒng)24*7無間斷對(duì)外服務(wù)。CAP理論中已經(jīng)說明了，分布式系統(tǒng)不能同時(shí)滿足強(qiáng)一致性和高可用性，應(yīng)該根據(jù)具體的業(yè)務(wù)做取舍，也就是說在分布式系統(tǒng)進(jìn)行架構(gòu)設(shè)計(jì)的過程中，往往會(huì)在可用性和一致性之間進(jìn)行反復(fù)的權(quán)衡，于是產(chǎn)生了一些列的一致性協(xié)議

二、2PC和3PC

當(dāng)一個(gè)事物操作需要跨越多個(gè)分布式節(jié)點(diǎn)的時(shí)候，為了保持事物處理的ACID特征，需要引入一個(gè)“協(xié)調(diào)者”的組件來統(tǒng)一調(diào)度所有分布式節(jié)點(diǎn)的執(zhí)行邏輯，這些被調(diào)度的分布式節(jié)點(diǎn)稱為“參與者”，協(xié)調(diào)者負(fù)責(zé)調(diào)度參與者的行為，并最終決定這些參與者是都要把事物真正的提交?；谶@個(gè)思想，衍生出了二階段提交和三階段提交兩種協(xié)議。

1、2PC

2PC:為了使基于分布式系統(tǒng)架構(gòu)下的所有節(jié)點(diǎn)在進(jìn)行事物處理過程中能夠保持原子性和一致性而設(shè)計(jì)的算法。目前絕大數(shù)關(guān)系型數(shù)據(jù)庫(比如mysql)都是采用兩階段提交來完成事物處理的。核心思想：參與者將操作成敗通知協(xié)調(diào)者，再由協(xié)調(diào)者根據(jù)所有參與者的反饋情報(bào)決定各參與者是否要提交操作還是中止操作操作過程：

1、提交事物請(qǐng)求(投票階段):

協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)詢問是否可以執(zhí)行提交操作，并開始等待各參與者節(jié)點(diǎn)的響應(yīng)。

參與者節(jié)點(diǎn)執(zhí)行詢問發(fā)起為止的所有事務(wù)操作，并將Undo信息和Redo信息寫入日志。

各參與者節(jié)點(diǎn)響應(yīng)協(xié)調(diào)者節(jié)點(diǎn)發(fā)起的詢問。如果參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行成功，則它返回一個(gè)”同意”消息;如果參與者節(jié)點(diǎn)的事務(wù)操作實(shí)際執(zhí)行失敗，則它返回一個(gè)”中止”消息2、執(zhí)行事物提交(執(zhí)行階段)：

在該階段，協(xié)調(diào)者將基于第一個(gè)階段的投票結(jié)果進(jìn)行決策：提交或取消。當(dāng)且僅當(dāng)所有的參與者同意提交事務(wù)協(xié)調(diào)者才通知所有的參與者提交事務(wù)，否則協(xié)調(diào)者將通知所有的參與者取消事務(wù)。參與者在接收到協(xié)調(diào)者發(fā)來的消息后將執(zhí)行響應(yīng)的操作。

會(huì)產(chǎn)生的問題：

(1)同步阻塞。在兩階段提交的執(zhí)行過程中，所有的參與者操作的邏輯都是處于阻塞狀態(tài)，各個(gè)參與者在等待其他參與者響應(yīng)的過程中，將無法進(jìn)行其他任何操作。coordinator如果在發(fā)起提議后宕機(jī)，那么participant將進(jìn)入阻塞(block)狀態(tài)、一直等待coordinator回應(yīng)以完成該次決議。(2)單點(diǎn)問題。協(xié)調(diào)者會(huì)有單點(diǎn)問題。(3)數(shù)據(jù)不一致。網(wǎng)絡(luò)原因或者其他原因會(huì)導(dǎo)致部分commit部分沒有執(zhí)行commit，產(chǎn)生數(shù)據(jù)不一致。(4)太過保守。就是說在兩階段中，任意一個(gè)節(jié)點(diǎn)的失敗都會(huì)導(dǎo)致整個(gè)事物失敗。

2、3PC

三階段提交：三階段提交協(xié)議在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制，并且把兩階段提交協(xié)議的第一個(gè)階段拆分成了兩步：詢問，然后再鎖資源，最后真正提交。形成canCOmmit、PreCommit、和doCommit三個(gè)階段組成的事物處理協(xié)議。

與2PC比較：(1)相對(duì)于2PC，3PC能降低參與者阻塞范圍，主要通過參與者引入超時(shí)機(jī)制(在2PC中，只有協(xié)調(diào)者擁有超時(shí)機(jī)制，即如果在一定時(shí)間內(nèi)沒有收到cohort的消息則默認(rèn)失敗)(3)2PC的準(zhǔn)備階段和提交階段之間，插入預(yù)提交階段，使3PC擁有CanCommit、PreCommit、DoCommit三個(gè)階段。PreCommit是一個(gè)緩沖，保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。(極端情況下面還是會(huì)出現(xiàn)不一致，如果進(jìn)入PreCommit后，Coordinator發(fā)出的是abort請(qǐng)求，假設(shè)只有一個(gè)Cohort收到并進(jìn)行了abort操作，而其他對(duì)于系統(tǒng)狀態(tài)未知的Cohort會(huì)根據(jù)3PC選擇繼續(xù)Commit，此時(shí)系統(tǒng)狀態(tài)發(fā)生不一致性。)3PC如何應(yīng)對(duì)宕機(jī)：

在階段1中： coordinator或watchdog未收到宕機(jī)participant的vote，直接中止事務(wù);宕機(jī)的participant恢復(fù)后，讀取logging發(fā)現(xiàn)未發(fā)出贊成vote，自行中止該次事務(wù)在階段2中: coordinator未收到宕機(jī)participant的precommit ACK，但因?yàn)橹耙呀?jīng)收到了宕機(jī)participant的贊成反饋(不然也不會(huì)進(jìn)入到階段2)，coordinator進(jìn)行commit;宕機(jī)的participant恢復(fù)后發(fā)現(xiàn)收到precommit或已經(jīng)發(fā)出贊成vote，則自行commit該次事務(wù)在階段3中： 即便coordinator或watchdog未收到宕機(jī)participant的commit ACK，也結(jié)束該次事務(wù);宕機(jī)的participant恢復(fù)后發(fā)現(xiàn)收到commit或者precommit，也將自行commit該次事務(wù)