轉(zhuǎn)自： https://blog.csdn.net/bjweimengshu/article/details/79607522

假如沒有分布式事務(wù)

在一系列微服務(wù)系統(tǒng)當(dāng)中，假如不存在分布式事務(wù)，會(huì)發(fā)生什么呢？讓我們以互聯(lián)網(wǎng)中常用的交易業(yè)務(wù)為例子：

上圖中包含了庫(kù)存和訂單兩個(gè)獨(dú)立的微服務(wù)，每個(gè)微服務(wù)維護(hù)了自己的數(shù)據(jù)庫(kù)。在交易系統(tǒng)的業(yè)務(wù)邏輯中，一個(gè)商品在下單之前需要先調(diào)用庫(kù)存服務(wù)，進(jìn)行扣除庫(kù)存，再調(diào)用訂單服務(wù)，創(chuàng)建訂單記錄。

正常情況下，兩個(gè)數(shù)據(jù)庫(kù)各自更新成功，兩邊數(shù)據(jù)維持著一致性。

但是，在非正常情況下，有可能庫(kù)存的扣減完成了，隨后的訂單記錄卻因?yàn)槟承┰虿迦胧　＿@個(gè)時(shí)候，兩邊數(shù)據(jù)就失去了應(yīng)有的一致性。

什么是分布式事務(wù)？

分布式事務(wù)用于在分布式系統(tǒng)中保證不同節(jié)點(diǎn)之間的數(shù)據(jù)一致性。分布式事務(wù)的實(shí)現(xiàn)有很多種，最具有代表性的是由Oracle Tuxedo系統(tǒng)提出的XA分布式事務(wù)協(xié)議。

XA協(xié)議包含兩階段提交（2PC）和三階段提交（3PC）兩種實(shí)現(xiàn)，這里我們重點(diǎn)介紹兩階段提交的具體過程。

在魔獸世界這款游戲中，副本組團(tuán)打BOSS的時(shí)候，為了更方便隊(duì)長(zhǎng)與隊(duì)員們之間的協(xié)作，隊(duì)長(zhǎng)可以發(fā)起一個(gè)“就位確認(rèn)”的操作：

當(dāng)隊(duì)員收到就位確認(rèn)提示后，如果已經(jīng)就位，就選擇“是”，如果還沒就位，就選擇“否”。

當(dāng)隊(duì)長(zhǎng)收到了所有人的就位確認(rèn)，就會(huì)向所有隊(duì)員們發(fā)布消息，告訴他們開始打BOSS。

相應(yīng)的，在隊(duì)長(zhǎng)發(fā)起就位確認(rèn)的時(shí)候，有可能某些隊(duì)員還并沒有就位：

以上就是魔獸世界當(dāng)中組團(tuán)打BOSS的確認(rèn)流程。這個(gè)流程和XA分布式事務(wù)協(xié)議的兩階段提交非常相似。

那么XA協(xié)議究竟是什么樣子呢？在XA協(xié)議中包含著兩個(gè)角色：事務(wù)協(xié)調(diào)者和事務(wù)參與者。讓我們來看一看他們之間的交互流程：

第一階段：

在XA分布式事務(wù)的第一階段，作為事務(wù)協(xié)調(diào)者的節(jié)點(diǎn)會(huì)首先向所有的參與者節(jié)點(diǎn)發(fā)送Prepare請(qǐng)求。

在接到Prepare請(qǐng)求之后，每一個(gè)參與者節(jié)點(diǎn)會(huì)各自執(zhí)行與事務(wù)有關(guān)的數(shù)據(jù)更新，寫入U(xiǎn)ndo Log和Redo Log。如果參與者執(zhí)行成功，暫時(shí)不提交事務(wù)，而是向事務(wù)協(xié)調(diào)節(jié)點(diǎn)返回“完成”消息。

當(dāng)事務(wù)協(xié)調(diào)者接到了所有參與者的返回消息，整個(gè)分布式事務(wù)將會(huì)進(jìn)入第二階段。

第二階段：

在XA分布式事務(wù)的第二階段，如果事務(wù)協(xié)調(diào)節(jié)點(diǎn)在之前所收到都是正向返回，那么它將會(huì)向所有事務(wù)參與者發(fā)出Commit請(qǐng)求。

接到Commit請(qǐng)求之后，事務(wù)參與者節(jié)點(diǎn)會(huì)各自進(jìn)行本地的事務(wù)提交，并釋放鎖資源。當(dāng)本地事務(wù)完成提交后，將會(huì)向事務(wù)協(xié)調(diào)者返回“完成”消息。

當(dāng)事務(wù)協(xié)調(diào)者接收到所有事務(wù)參與者的“完成”反饋，整個(gè)分布式事務(wù)完成。

以上所描述的是XA兩階段提交的正向流程，接下來我們看一看失敗情況的處理流程：

第一階段：

第二階段：

在XA的第一階段，如果某個(gè)事務(wù)參與者反饋失敗消息，說明該節(jié)點(diǎn)的本地事務(wù)執(zhí)行不成功，必須回滾。

于是在第二階段，事務(wù)協(xié)調(diào)節(jié)點(diǎn)向所有的事務(wù)參與者發(fā)送Abort請(qǐng)求。接收到Abort請(qǐng)求之后，各個(gè)事務(wù)參與者節(jié)點(diǎn)需要在本地進(jìn)行事務(wù)的回滾操作，回滾操作依照Undo Log來進(jìn)行。

以上就是XA兩階段提交協(xié)議的詳細(xì)過程。

XA兩階段提交的不足

XA兩階段提交究竟有哪些不足呢？

1.性能問題

XA協(xié)議遵循強(qiáng)一致性。在事務(wù)執(zhí)行過程中，各個(gè)節(jié)點(diǎn)占用著數(shù)據(jù)庫(kù)資源，只有當(dāng)所有節(jié)點(diǎn)準(zhǔn)備完畢，事務(wù)協(xié)調(diào)者才會(huì)通知提交，參與者提交后釋放資源。這樣的過程有著非常明顯的性能問題。

2.協(xié)調(diào)者單點(diǎn)故障問題

事務(wù)協(xié)調(diào)者是整個(gè)XA模型的核心，一旦事務(wù)協(xié)調(diào)者節(jié)點(diǎn)掛掉，參與者收不到提交或是回滾通知，參與者會(huì)一直處于中間狀態(tài)無法完成事務(wù)。

3.丟失消息導(dǎo)致的不一致問題。

在XA協(xié)議的第二個(gè)階段，如果發(fā)生局部網(wǎng)絡(luò)問題，一部分事務(wù)參與者收到了提交消息，另一部分事務(wù)參與者沒收到提交消息，那么就導(dǎo)致了節(jié)點(diǎn)之間數(shù)據(jù)的不一致。

如果避免XA兩階段提交的種種問題呢？有許多其他的分布式事務(wù)方案可供選擇：

1.XA三階段提交

XA三階段提交在兩階段提交的基礎(chǔ)上增加了CanCommit階段，并且引入了超時(shí)機(jī)制。一旦事物參與者遲遲沒有接到協(xié)調(diào)者的commit請(qǐng)求，會(huì)自動(dòng)進(jìn)行本地commit。這樣有效解決了協(xié)調(diào)者單點(diǎn)故障的問題。但是性能問題和不一致的問題仍然沒有根本解決。

2.MQ事務(wù)

利用消息中間件來異步完成事務(wù)的后一半更新，實(shí)現(xiàn)系統(tǒng)的最終一致性。這個(gè)方式避免了像XA協(xié)議那樣的性能問題。

3.TCC事務(wù)

TCC事務(wù)是Try、Commit、Cancel三種指令的縮寫，其邏輯模式類似于XA兩階段提交，但是實(shí)現(xiàn)方式是在代碼層面來人為實(shí)現(xiàn)。
————————————————
版權(quán)聲明：本文為CSDN博主「程序員小灰」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/bjweimengshu/article/details/79607522

總結(jié)

以上是生活随笔為你收集整理的（转）漫画：什么是分布式事务？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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