分布式事務(wù)

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

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

二階提交協(xié)議和三階提交協(xié)議就是根據(jù)這一思想衍生出來的半沽。可以說二階段提交其實(shí)就是實(shí)現(xiàn)XA分布式事務(wù)的關(guān)鍵(確切地說：兩階段提交主要保證了分布式事務(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)。通常做葵，二階段提交也被稱為是一種協(xié)議(Protocol))占哟。在分布式系統(tǒng)中，每個(gè)節(jié)點(diǎn)雖然可以知曉自己的操作時(shí)成功或者失敗酿矢，卻無法知道其他節(jié)點(diǎn)的操作的成功或失敗榨乎。當(dāng)一個(gè)事務(wù)跨越多個(gè)節(jié)點(diǎn)時(shí)，為了保持事務(wù)的ACID特性瘫筐，需要引入一個(gè)作為協(xié)調(diào)者的組件來統(tǒng)一掌控所有節(jié)點(diǎn)(稱作參與者)的操作結(jié)果并最終指示這些節(jié)點(diǎn)是否要把操作結(jié)果進(jìn)行真正的提交(比如將更新后的數(shù)據(jù)寫入磁盤等等)蜜暑。因此，二階段提交的算法思路可以概括為：參與者將操作成敗通知協(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ù)，寫本地的redo和undo日志棺禾，但不提交缀蹄，到達(dá)一種“萬事俱備，只欠東風(fēng)”的狀態(tài)。
可以進(jìn)一步將準(zhǔn)備階段分為以下三個(gè)步驟：
1）協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)詢問是否可以執(zhí)行提交操作(vote)缺前，并開始等待各參與者節(jié)點(diǎn)的響應(yīng)蛀醉。
2）參與者節(jié)點(diǎn)執(zhí)行詢問發(fā)起為止的所有事務(wù)操作，并將Undo信息和Redo信息寫入日志诡延。（注意：若成功這里其實(shí)每個(gè)參與者已經(jīng)執(zhí)行了事務(wù)操作）
3）各參與者節(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è)”中止”消息。

提交階段
如果協(xié)調(diào)者收到了參與者的失敗消息或者超時(shí)惹恃，直接給每個(gè)參與者發(fā)送回滾(Rollback)消息夭谤；否則，發(fā)送提交(Commit)消息巫糙；參與者根據(jù)協(xié)調(diào)者的指令執(zhí)行提交或者回滾操作朗儒，釋放所有事務(wù)處理過程中使用的鎖資源。(注意:必須在最后階段釋放鎖資源)
接下來分兩種情況分別討論提交階段的過程参淹。
當(dāng)協(xié)調(diào)者節(jié)點(diǎn)從所有參與者節(jié)點(diǎn)獲得的相應(yīng)消息都為”同意”時(shí):

success

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)在第一階段的詢問超時(shí)之前無法獲取所有參與者節(jié)點(diǎn)的響應(yīng)消息時(shí)：

fail

1）協(xié)調(diào)者節(jié)點(diǎn)向所有參與者節(jié)點(diǎn)發(fā)出”回滾操作(rollback)”的請(qǐng)求。
2）參與者節(jié)點(diǎn)利用之前寫入的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ù)较解。
二階段提交看起來確實(shí)能夠提供原子性的操作畜疾，但是不幸的事，二階段提交還是有幾個(gè)缺點(diǎn)的：
1哨坪、同步阻塞問題庸疾。執(zhí)行過程中乍楚，所有參與節(jié)點(diǎn)都是事務(wù)阻塞型的当编。當(dāng)參與者占有公共資源時(shí)，其他第三方節(jié)點(diǎn)訪問公共資源不得不處于阻塞狀態(tài)徒溪。
2忿偷、單點(diǎn)故障金顿。由于協(xié)調(diào)者的重要性，一旦協(xié)調(diào)者發(fā)生故障鲤桥。參與者會(huì)一直阻塞下去揍拆。尤其在第二階段，協(xié)調(diào)者發(fā)生故障茶凳，那么所有的參與者還都處于鎖定事務(wù)資源的狀態(tài)中嫂拴，而無法繼續(xù)完成事務(wù)操作。（如果是協(xié)調(diào)者掛掉贮喧，可以重新選舉一個(gè)協(xié)調(diào)者筒狠，但是無法解決因?yàn)閰f(xié)調(diào)者宕機(jī)導(dǎo)致的參與者處于阻塞狀態(tài)的問題）
3、數(shù)據(jù)不一致箱沦。在二階段提交的階段二中辩恼，當(dāng)協(xié)調(diào)者向參與者發(fā)送commit請(qǐng)求之后，發(fā)生了局部網(wǎng)絡(luò)異澄叫危或者在發(fā)送commit請(qǐng)求過程中協(xié)調(diào)者發(fā)生了故障灶伊，這回導(dǎo)致只有一部分參與者接受到了commit請(qǐng)求。而在這部分參與者接到commit請(qǐng)求之后就會(huì)執(zhí)行commit操作寒跳。但是其他部分未接到commit請(qǐng)求的機(jī)器則無法執(zhí)行事務(wù)提交聘萨。于是整個(gè)分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)部一致性的現(xiàn)象。
4冯袍、二階段無法解決的問題：協(xié)調(diào)者再發(fā)出commit消息之后宕機(jī)匈挖，而唯一接收到這條消息的參與者同時(shí)也宕機(jī)了。那么即使協(xié)調(diào)者通過選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者康愤，這條事務(wù)的狀態(tài)也是不確定的儡循，沒人知道事務(wù)是否被已經(jīng)提交。

由于二階段提交存在著諸如同步阻塞征冷、單點(diǎn)問題择膝、腦裂等缺陷，所以检激，研究者們?cè)诙A段提交的基礎(chǔ)上做了改進(jìn)肴捉，提出了三階段提交。
3PC
三階段提交（Three-phase commit）叔收，也叫三階段提交協(xié)議（Three-phase commit protocol）齿穗，是二階段提交（2PC）的改進(jìn)版本。

3

PreCommit階段
協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來決定是否可以記性事務(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í)開始等待最終指令艺糜。

假如有任何一個(gè)參與者向協(xié)調(diào)者發(fā)送了No響應(yīng)阀湿，或者等待超時(shí)之后，協(xié)調(diào)者都沒有接到參與者的響應(yīng)领猾，那么就執(zhí)行事務(wù)的中斷米同。
1.發(fā)送中斷請(qǐng)求 協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求求冷。
2.中斷事務(wù) 參與者收到來自協(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)者沒有接收到參與者發(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信息來執(zhí)行事務(wù)的回滾操作虐拓，并在完成回滾之后釋放所有的事務(wù)資源。
3.反饋結(jié)果 參與者完成事務(wù)回滾之后傲武，向協(xié)調(diào)者發(fā)送ACK消息
4.中斷事務(wù) 協(xié)調(diào)者接收到參與者反饋的ACK消息之后蓉驹，執(zhí)行事務(wù)的中斷。

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

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