隨著大型網(wǎng)站的各種高并發(fā)訪問(wèn)、海量數(shù)據(jù)處理等場(chǎng)景越來(lái)越多，如何實(shí)現(xiàn)網(wǎng)站的高可用、易伸縮、可擴(kuò)展、安全等目標(biāo)就顯得越來(lái)越重要。為了解決這樣一系列問(wèn)題，大型網(wǎng)站的架構(gòu)也在不斷發(fā)展。提高大型網(wǎng)站的高可用架構(gòu)，不得不提的就是分布式。在分布式一致性一文中主要介紹了分布式系統(tǒng)中存在的一致性問(wèn)題。本文將簡(jiǎn)單介紹如何有效的解決分布式的一致性問(wèn)題,其中包括什么是分布式事務(wù)，二階段提交和三階段提交。

分布式一致性回顧

在分布式系統(tǒng)中，為了保證數(shù)據(jù)的高可用，通常，我們會(huì)將數(shù)據(jù)保留多個(gè)副本(replica)，這些副本會(huì)放置在不同的物理的機(jī)器上。為了對(duì)用戶(hù)提供正確的增\刪\改\差等語(yǔ)義，我們需要保證這些放置在不同物理機(jī)器上的副本是一致的。

為了解決這種分布式一致性問(wèn)題，前人在性能和數(shù)據(jù)一致性的反反復(fù)復(fù)權(quán)衡過(guò)程中總結(jié)了許多典型的協(xié)議和算法。其中比較著名的有二階提交協(xié)議（Two Phase Commitment Protocol）、三階提交協(xié)議（Three Phase Commitment Protocol）和Paxos算法。

分布式事務(wù)

分布式事務(wù)是指會(huì)涉及到操作多個(gè)數(shù)據(jù)庫(kù)的事務(wù)。其實(shí)就是將對(duì)同一庫(kù)事務(wù)的概念擴(kuò)大到了對(duì)多個(gè)庫(kù)的事務(wù)。目的是為了保證分布式系統(tǒng)中的數(shù)據(jù)一致性。分布式事務(wù)處理的關(guān)鍵是必須有一種方法可以知道事務(wù)在任何地方所做的所有動(dòng)作，提交或回滾事務(wù)的決定必須產(chǎn)生統(tǒng)一的結(jié)果（全部提交或全部回滾）

在分布式系統(tǒng)中，各個(gè)節(jié)點(diǎn)之間在物理上相互獨(dú)立，通過(guò)網(wǎng)絡(luò)進(jìn)行溝通和協(xié)調(diào)。由于存在事務(wù)機(jī)制，可以保證每個(gè)獨(dú)立節(jié)點(diǎn)上的數(shù)據(jù)操作可以滿(mǎn)足ACID。但是，相互獨(dú)立的節(jié)點(diǎn)之間無(wú)法準(zhǔn)確的知道其他節(jié)點(diǎn)中的事務(wù)執(zhí)行情況。所以從理論上講，兩臺(tái)機(jī)器理論上無(wú)法達(dá)到一致的狀態(tài)。如果想讓分布式部署的多臺(tái)機(jī)器中的數(shù)據(jù)保持一致性，那么就要保證在所有節(jié)點(diǎn)的數(shù)據(jù)寫(xiě)操作，要不全部都執(zhí)行，要么全部的都不執(zhí)行。但是，一臺(tái)機(jī)器在執(zhí)行本地事務(wù)的時(shí)候無(wú)法知道其他機(jī)器中的本地事務(wù)的執(zhí)行結(jié)果。所以他也就不知道本次事務(wù)到底應(yīng)該commit還是 roolback。所以，常規(guī)的解決辦法就是引入一個(gè)“協(xié)調(diào)者”的組件來(lái)統(tǒng)一調(diào)度所有分布式節(jié)點(diǎn)的執(zhí)行。

XA規(guī)范

X/Open?組織（即現(xiàn)在的?Open?Group?）定義了分布式事務(wù)處理模型。?X/Open?DTP?模型（?1994?）包括應(yīng)用程序（?AP?）、事務(wù)管理器（?TM?）、資源管理器（?RM?）、通信資源管理器（?CRM?）四部分。一般，常見(jiàn)的事務(wù)管理器（?TM?）是交易中間件，常見(jiàn)的資源管理器（?RM?）是數(shù)據(jù)庫(kù)，常見(jiàn)的通信資源管理器（?CRM?）是消息中間件。? ??通常把一個(gè)數(shù)據(jù)庫(kù)內(nèi)部的事務(wù)處理，如對(duì)多個(gè)表的操作，作為本地事務(wù)看待。數(shù)據(jù)庫(kù)的事務(wù)處理對(duì)象是本地事務(wù)，而分布式事務(wù)處理的對(duì)象是全局事務(wù)。?? 所謂全局事務(wù)，是指分布式事務(wù)處理環(huán)境中，多個(gè)數(shù)據(jù)庫(kù)可能需要共同完成一個(gè)工作，這個(gè)工作即是一個(gè)全局事務(wù)，例如，一個(gè)事務(wù)中可能更新幾個(gè)不同的數(shù)據(jù)庫(kù)。對(duì)數(shù)據(jù)庫(kù)的操作發(fā)生在系統(tǒng)的各處但必須全部被提交或回滾。此時(shí)一個(gè)數(shù)據(jù)庫(kù)對(duì)自己內(nèi)部所做操作的提交不僅依賴(lài)本身操作是否成功，還要依賴(lài)與全局事務(wù)相關(guān)的其它數(shù)據(jù)庫(kù)的操作是否成功，如果任一數(shù)據(jù)庫(kù)的任一操作失敗，則參與此事務(wù)的所有數(shù)據(jù)庫(kù)所做的所有操作都必須回滾。?? ??一般情況下，某一數(shù)據(jù)庫(kù)無(wú)法知道其它數(shù)據(jù)庫(kù)在做什么，因此，在一個(gè)?DTP?環(huán)境中，交易中間件是必需的，由它通知和協(xié)調(diào)相關(guān)數(shù)據(jù)庫(kù)的提交或回滾。而一個(gè)數(shù)據(jù)庫(kù)只將其自己所做的操作（可恢復(fù)）影射到全局事務(wù)中。????

XA?就是?X/Open?DTP?定義的交易中間件與數(shù)據(jù)庫(kù)之間的接口規(guī)范（即接口函數(shù)），交易中間件用它來(lái)通知數(shù)據(jù)庫(kù)事務(wù)的開(kāi)始、結(jié)束以及提交、回滾等。?XA?接口函數(shù)由數(shù)據(jù)庫(kù)廠商提供。?

二階提交協(xié)議和三階提交協(xié)議就是根據(jù)這一思想衍生出來(lái)的?？梢哉f(shuō)二階段提交其實(shí)就是實(shí)現(xiàn)XA分布式事務(wù)的關(guān)鍵(確切地說(shuō)：兩階段提交主要保證了分布式事務(wù)的原子性：即所有結(jié)點(diǎn)要么全做要么全不做)

2PC

二階段提交(Two-phaseCommit)是指，在計(jì)算機(jī)網(wǎng)絡(luò)以及數(shù)據(jù)庫(kù)領(lǐng)域內(nèi)，為了使基于分布式系統(tǒng)架構(gòu)下的所有節(jié)點(diǎn)在進(jìn)行事務(wù)提交時(shí)保持一致性而設(shè)計(jì)的一種算法(Algorithm)。通常，二階段提交也被稱(chēng)為是一種協(xié)議(Protocol))。在分布式系統(tǒng)中，每個(gè)節(jié)點(diǎn)雖然可以知曉自己的操作時(shí)成功或者失敗，卻無(wú)法知道其他節(jié)點(diǎn)的操作的成功或失敗。當(dāng)一個(gè)事務(wù)跨越多個(gè)節(jié)點(diǎn)時(shí)，為了保持事務(wù)的ACID特性，需要引入一個(gè)作為協(xié)調(diào)者的組件來(lái)統(tǒng)一掌控所有節(jié)點(diǎn)(稱(chēng)作參與者)的操作結(jié)果并最終指示這些節(jié)點(diǎn)是否要把操作結(jié)果進(jìn)行真正的提交(比如將更新后的數(shù)據(jù)寫(xiě)入磁盤(pán)等等)。因此，二階段提交的算法思路可以概括為：參與者將操作成敗通知協(xié)調(diào)者，再由協(xié)調(diào)者根據(jù)所有參與者的反饋情報(bào)決定各參與者是否要提交操作還是中止操作。

所謂的兩個(gè)階段是指：第一階段：準(zhǔn)備階段(投票階段)和第二階段：提交階段（執(zhí)行階段）。

準(zhǔn)備階段

事務(wù)協(xié)調(diào)者(事務(wù)管理器)給每個(gè)參與者(資源管理器)發(fā)送Prepare消息，每個(gè)參與者要么直接返回失敗(如權(quán)限驗(yàn)證失敗)，要么在本地執(zhí)行事務(wù)，寫(xiě)本地的redo和undo日志，但不提交，到達(dá)一種“萬(wàn)事俱備，只欠東風(fēng)”的狀態(tài)。

可以進(jìn)一步將準(zhǔn)備階段分為以下三個(gè)步驟：

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

2）參與者節(jié)點(diǎn)執(zhí)行詢(xún)問(wèn)發(fā)起為止的所有事務(wù)操作，并將Undo信息和Redo信息寫(xiě)入日志。（注意：若成功這里其實(shí)每個(gè)參與者已經(jīng)執(zhí)行了事務(wù)操作）

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

提交階段

如果協(xié)調(diào)者收到了參與者的失敗消息或者超時(shí)，直接給每個(gè)參與者發(fā)送回滾(Rollback)消息；否則，發(fā)送提交(Commit)消息；參與者根據(jù)協(xié)調(diào)者的指令執(zhí)行提交或者回滾操作，釋放所有事務(wù)處理過(guò)程中使用的鎖資源。(注意:必須在最后階段釋放鎖資源)

接下來(lái)分兩種情況分別討論提交階段的過(guò)程。

當(dāng)協(xié)調(diào)者節(jié)點(diǎn)從所有參與者節(jié)點(diǎn)獲得的相應(yīng)消息都為”同意”時(shí):

1）協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出”正式提交(commit)”的請(qǐng)求。

2）參與者節(jié)點(diǎn)正式完成操作，并釋放在整個(gè)事務(wù)期間內(nèi)占用的資源。

3）參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送”完成”消息。

4）協(xié)調(diào)者節(jié)點(diǎn)受到所有參與者節(jié)點(diǎn)反饋的”完成”消息后，完成事務(wù)。

如果任一參與者節(jié)點(diǎn)在第一階段返回的響應(yīng)消息為”中止”，或者 協(xié)調(diào)者節(jié)點(diǎn)在第一階段的詢(xún)問(wèn)超時(shí)之前無(wú)法獲取所有參與者節(jié)點(diǎn)的響應(yīng)消息時(shí)：

1）協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出”回滾操作(rollback)”的請(qǐng)求。

2）參與者節(jié)點(diǎn)利用之前寫(xiě)入的Undo信息執(zhí)行回滾，并釋放在整個(gè)事務(wù)期間內(nèi)占用的資源。

3）參與者節(jié)點(diǎn)向協(xié)調(diào)者節(jié)點(diǎn)發(fā)送”回滾完成”消息。

4）協(xié)調(diào)者節(jié)點(diǎn)受到所有參與者節(jié)點(diǎn)反饋的”回滾完成”消息后，取消事務(wù)。

　　不管最后結(jié)果如何，第二階段都會(huì)結(jié)束當(dāng)前事務(wù)。

二階段提交看起來(lái)確實(shí)能夠提供原子性的操作，但是不幸的事，二階段提交還是有幾個(gè)缺點(diǎn)的：

1、同步阻塞問(wèn)題。執(zhí)行過(guò)程中，所有參與節(jié)點(diǎn)都是事務(wù)阻塞型的。當(dāng)參與者占有公共資源時(shí)，其他第三方節(jié)點(diǎn)訪問(wèn)公共資源不得不處于阻塞狀態(tài)。

2、單點(diǎn)故障。由于協(xié)調(diào)者的重要性，一旦協(xié)調(diào)者發(fā)生故障。參與者會(huì)一直阻塞下去。尤其在第二階段，協(xié)調(diào)者發(fā)生故障，那么所有的參與者還都處于鎖定事務(wù)資源的狀態(tài)中，而無(wú)法繼續(xù)完成事務(wù)操作。（如果是協(xié)調(diào)者掛掉，可以重新選舉一個(gè)協(xié)調(diào)者，但是無(wú)法解決因?yàn)閰f(xié)調(diào)者宕機(jī)導(dǎo)致的參與者處于阻塞狀態(tài)的問(wèn)題）

3、數(shù)據(jù)不一致。在二階段提交的階段二中，當(dāng)協(xié)調(diào)者向參與者發(fā)送commit請(qǐng)求之后，發(fā)生了局部網(wǎng)絡(luò)異?；蛘咴诎l(fā)送commit請(qǐng)求過(guò)程中協(xié)調(diào)者發(fā)生了故障，這回導(dǎo)致只有一部分參與者接受到了commit請(qǐng)求。而在這部分參與者接到commit請(qǐng)求之后就會(huì)執(zhí)行commit操作。但是其他部分未接到commit請(qǐng)求的機(jī)器則無(wú)法執(zhí)行事務(wù)提交。于是整個(gè)分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)部一致性的現(xiàn)象。

4、二階段無(wú)法解決的問(wèn)題：協(xié)調(diào)者再發(fā)出commit消息之后宕機(jī)，而唯一接收到這條消息的參與者同時(shí)也宕機(jī)了。那么即使協(xié)調(diào)者通過(guò)選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者，這條事務(wù)的狀態(tài)也是不確定的，沒(méi)人知道事務(wù)是否被已經(jīng)提交。

由于二階段提交存在著諸如同步阻塞、單點(diǎn)問(wèn)題、腦裂等缺陷，所以，研究者們?cè)诙A段提交的基礎(chǔ)上做了改進(jìn)，提出了三階段提交。

3PC

三階段提交（Three-phase commit），也叫三階段提交協(xié)議（Three-phase commit protocol），是二階段提交（2PC）的改進(jìn)版本。

與兩階段提交不同的是，三階段提交有兩個(gè)改動(dòng)點(diǎn)。

1、引入超時(shí)機(jī)制。同時(shí)在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制。 2、在第一階段和第二階段中插入一個(gè)準(zhǔn)備階段。保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。

也就是說(shuō)，除了引入超時(shí)機(jī)制之外，3PC把2PC的準(zhǔn)備階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個(gè)階段。

CanCommit階段

3PC的CanCommit階段其實(shí)和2PC的準(zhǔn)備階段很像。協(xié)調(diào)者向參與者發(fā)送commit請(qǐng)求，參與者如果可以提交就返回Yes響應(yīng)，否則返回No響應(yīng)。

1.事務(wù)詢(xún)問(wèn)?協(xié)調(diào)者向參與者發(fā)送CanCommit請(qǐng)求。詢(xún)問(wèn)是否可以執(zhí)行事務(wù)提交操作。然后開(kāi)始等待參與者的響應(yīng)。

2.響應(yīng)反饋?參與者接到CanCommit請(qǐng)求之后，正常情況下，如果其自身認(rèn)為可以順利執(zhí)行事務(wù)，則返回Yes響應(yīng)，并進(jìn)入預(yù)備狀態(tài)。否則反饋No

PreCommit階段

協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來(lái)決定是否可以記性事務(wù)的PreCommit操作。根據(jù)響應(yīng)情況，有以下兩種可能。

假如協(xié)調(diào)者從所有的參與者獲得的反饋都是Yes響應(yīng)，那么就會(huì)執(zhí)行事務(wù)的預(yù)執(zhí)行。

1.發(fā)送預(yù)提交請(qǐng)求?協(xié)調(diào)者向參與者發(fā)送PreCommit請(qǐng)求，并進(jìn)入Prepared階段。

2.事務(wù)預(yù)提交?參與者接收到PreCommit請(qǐng)求后，會(huì)執(zhí)行事務(wù)操作，并將undo和redo信息記錄到事務(wù)日志中。

3.響應(yīng)反饋?如果參與者成功的執(zhí)行了事務(wù)操作，則返回ACK響應(yīng)，同時(shí)開(kāi)始等待最終指令。

假如有任何一個(gè)參與者向協(xié)調(diào)者發(fā)送了No響應(yīng)，或者等待超時(shí)之后，協(xié)調(diào)者都沒(méi)有接到參與者的響應(yīng)，那么就執(zhí)行事務(wù)的中斷。

1.發(fā)送中斷請(qǐng)求?協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求。

2.中斷事務(wù)?參與者收到來(lái)自協(xié)調(diào)者的abort請(qǐng)求之后（或超時(shí)之后，仍未收到協(xié)調(diào)者的請(qǐng)求），執(zhí)行事務(wù)的中斷。

doCommit階段

該階段進(jìn)行真正的事務(wù)提交，也可以分為以下兩種情況。

執(zhí)行提交

1.發(fā)送提交請(qǐng)求?協(xié)調(diào)接收到參與者發(fā)送的ACK響應(yīng)，那么他將從預(yù)提交狀態(tài)進(jìn)入到提交狀態(tài)。并向所有參與者發(fā)送doCommit請(qǐng)求。

2.事務(wù)提交?參與者接收到doCommit請(qǐng)求之后，執(zhí)行正式的事務(wù)提交。并在完成事務(wù)提交之后釋放所有事務(wù)資源。

3.響應(yīng)反饋?事務(wù)提交完之后，向協(xié)調(diào)者發(fā)送Ack響應(yīng)。

4.完成事務(wù)?協(xié)調(diào)者接收到所有參與者的ack響應(yīng)之后，完成事務(wù)。

中斷事務(wù)?協(xié)調(diào)者沒(méi)有接收到參與者發(fā)送的ACK響應(yīng)（可能是接受者發(fā)送的不是ACK響應(yīng)，也可能響應(yīng)超時(shí)），那么就會(huì)執(zhí)行中斷事務(wù)。

1.發(fā)送中斷請(qǐng)求?協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求

2.事務(wù)回滾?參與者接收到abort請(qǐng)求之后，利用其在階段二記錄的undo信息來(lái)執(zhí)行事務(wù)的回滾操作，并在完成回滾之后釋放所有的事務(wù)資源。

3.反饋結(jié)果?參與者完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送ACK消息

4.中斷事務(wù)?協(xié)調(diào)者接收到參與者反饋的ACK消息之后，執(zhí)行事務(wù)的中斷。

在doCommit階段，如果參與者無(wú)法及時(shí)接收到來(lái)自協(xié)調(diào)者的doCommit或者rebort請(qǐng)求時(shí)，會(huì)在等待超時(shí)之后，會(huì)繼續(xù)進(jìn)行事務(wù)的提交。（其實(shí)這個(gè)應(yīng)該是基于概率來(lái)決定的，當(dāng)進(jìn)入第三階段時(shí)，說(shuō)明參與者在第二階段已經(jīng)收到了PreCommit請(qǐng)求，那么協(xié)調(diào)者產(chǎn)生PreCommit請(qǐng)求的前提條件是他在第二階段開(kāi)始之前，收到所有參與者的CanCommit響應(yīng)都是Yes。（一旦參與者收到了PreCommit，意味他知道大家其實(shí)都同意修改了）所以，一句話概括就是，當(dāng)進(jìn)入第三階段時(shí)，由于網(wǎng)絡(luò)超時(shí)等原因，雖然參與者沒(méi)有收到commit或者abort響應(yīng)，但是他有理由相信：成功提交的幾率很大。 ）

2PC與3PC的區(qū)別

相對(duì)于2PC，3PC主要解決的單點(diǎn)故障問(wèn)題，并減少阻塞，因?yàn)橐坏﹨⑴c者無(wú)法及時(shí)收到來(lái)自協(xié)調(diào)者的信息之后，他會(huì)默認(rèn)執(zhí)行commit。而不會(huì)一直持有事務(wù)資源并處于阻塞狀態(tài)。但是這種機(jī)制也會(huì)導(dǎo)致數(shù)據(jù)一致性問(wèn)題，因?yàn)?#xff0c;由于網(wǎng)絡(luò)原因，協(xié)調(diào)者發(fā)送的abort響應(yīng)沒(méi)有及時(shí)被參與者接收到，那么參與者在等待超時(shí)之后執(zhí)行了commit操作。這樣就和其他接到abort命令并執(zhí)行回滾的參與者之間存在數(shù)據(jù)不一致的情況。

---

了解了2PC和3PC之后，我們可以發(fā)現(xiàn)，無(wú)論是二階段提交還是三階段提交都無(wú)法徹底解決分布式的一致性問(wèn)題。Google Chubby的作者M(jìn)ike Burrows說(shuō)過(guò)，?there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos.?意即世上只有一種一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整版。后面的文章會(huì)介紹這個(gè)公認(rèn)為難于理解但是行之有效的Paxos算法。

參考資料：

分布式協(xié)議之兩階段提交協(xié)議（2PC）和改進(jìn)三階段提交協(xié)議（3PC）?關(guān)于分布式事務(wù)、兩階段提交、一階段提交、Best Efforts 1PC模式和事務(wù)補(bǔ)償機(jī)制的研究?兩階段提交協(xié)議與三階段提交協(xié)議

【公告】版權(quán)聲明

(全文完)

from:?http://www.hollischuang.com/archives/681

總結(jié)

以上是生活随笔為你收集整理的关于分布式事务、两阶段提交协议、三阶提交协议的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。