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

一、一致性問題

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

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

分布式面臨的問題：

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

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

二、2PC和3PC

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

1、2PC

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

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

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

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

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

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

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

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

2、3PC

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

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

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