一、分布式事務(wù)產(chǎn)生的原因
在傳統(tǒng)的單體應(yīng)用中肥矢，即使應(yīng)用有多個(gè)模塊端衰，這多個(gè)模塊使用一個(gè)數(shù)據(jù)源，不存在分布式事務(wù)的問(wèn)題橄抹。當(dāng)隨著需求的變化靴迫，單體應(yīng)用已不能滿足我們的需要，單體應(yīng)用被拆分為微服務(wù)系統(tǒng)楼誓，多個(gè)模塊被拆分為單獨(dú)的應(yīng)用服務(wù)玉锌，每個(gè)應(yīng)用都用獨(dú)自的數(shù)據(jù)庫(kù)事務(wù)。這樣疟羹，服務(wù)之間的數(shù)據(jù)一致性就無(wú)法保證主守。我們需要分布式的事務(wù)來(lái)保障全局的事務(wù)一致性。
二榄融、分布式事務(wù)的解決方案
1.基于XA協(xié)議的兩階段提交
XA是一個(gè)分布式事務(wù)協(xié)議参淫，XA包含兩個(gè)部分：事務(wù)管理器和資源管理器。資源管理器由數(shù)據(jù)庫(kù)實(shí)現(xiàn)愧杯，但是在mysql5.7之前的版本不支持XA協(xié)議涎才；事務(wù)管理器作為全局的調(diào)度者，負(fù)責(zé)各個(gè)本地資源的提交和回滾力九。XA兩端提交原理如下：
第一階段：
1.事務(wù)管理器通知各個(gè)事務(wù)的資源管理器開(kāi)始準(zhǔn)備事務(wù)耍铜。
2.資源管理器收到通知后進(jìn)入準(zhǔn)備階段，寫好事務(wù)日志并執(zhí)行事務(wù)跌前，但是不提交事務(wù)棕兼，只是將準(zhǔn)備就緒的消息返回給事務(wù)管理器。
第二階段：
1.事務(wù)管理器在接收各個(gè)資源管理器消息后開(kāi)始進(jìn)行分析抵乓，如果有任意一個(gè)失敗伴挚，則發(fā)送事務(wù)回滾命令靶衍，否則發(fā)送提交命令。
2.資源管理器在收到事務(wù)管理器的消息后茎芋，提交事務(wù)颅眶，并將提交信息返回給事務(wù)管理器。
XA分布式事務(wù)比較簡(jiǎn)單败徊，成本比較低帚呼，但是性能比較差，無(wú)法滿足高并發(fā)的業(yè)務(wù)場(chǎng)景皱蹦。
2.基于消息中間件的事物+最終一致性
基于消息中間件的事務(wù)煤杀，主要是通過(guò)將本地事務(wù)和消息發(fā)送放在一個(gè)事務(wù)里面，保證本地事務(wù)成功而且消息發(fā)送成功沪哺，否則的話兩者都失敗沈自，事務(wù)進(jìn)行回滾。如下圖：
1.1.A系統(tǒng)向消息中間件發(fā)送預(yù)備消息辜妓，一旦出錯(cuò)A系統(tǒng)的操作不會(huì)執(zhí)行
1.2.消息中間件保存預(yù)備消息并返回成功枯途，失敗則A系統(tǒng)的操作不執(zhí)行
2.A系統(tǒng)執(zhí)行本地事務(wù)，如果失敗則回滾事務(wù)
3.向消息中間件發(fā)送消息籍滴，消息中間件收到消息后先保存消息酪夷，然后發(fā)送給B系統(tǒng)，由B系統(tǒng)執(zhí)行本地事務(wù)孽惰，若消息中間件保存消息成功則A系統(tǒng)事務(wù)一定成功
4.消息中間件執(zhí)行回調(diào)接口給A系統(tǒng)發(fā)送消息晚岭，若系統(tǒng)成功收到回調(diào)消息，則證明B系統(tǒng)的事務(wù)也是成功的勋功，這樣就實(shí)現(xiàn)了最終一致性坦报。
消息中間件的解決方案雖然提高了系統(tǒng)性能，但是事務(wù)不是嚴(yán)格一致的狂鞋，如果B系統(tǒng)執(zhí)行失敗片择，A系統(tǒng)事務(wù)無(wú)法回滾。此外對(duì)消息中間件依賴較大骚揍，萬(wàn)一消息中間件不可用將會(huì)導(dǎo)致所有的業(yè)務(wù)都無(wú)法進(jìn)行字管。
3.TCC模式
TCC模式是由業(yè)務(wù)系統(tǒng)來(lái)實(shí)現(xiàn)的，通過(guò)對(duì)業(yè)務(wù)邏輯的調(diào)度來(lái)實(shí)現(xiàn)分布式事務(wù)信不，主要由三個(gè)操作組成：try纤掸，confirm，cancle浑塞。try:嘗試執(zhí)行業(yè)務(wù)，confirm:確認(rèn)執(zhí)行業(yè)務(wù)政己，cancle:取消執(zhí)行業(yè)務(wù)酌壕。
TCC模式對(duì)代碼的嵌入性高掏愁，要求每個(gè)業(yè)務(wù)都要寫這三步代碼，事務(wù)一致性由開(kāi)發(fā)者來(lái)控制卵牍，業(yè)務(wù)開(kāi)發(fā)難度比較高果港。
4.TXC模式
TXC模式為阿里開(kāi)源的GTS項(xiàng)目中命名的模式，項(xiàng)目地址：https://github.com/alibaba/fescar/wiki/%E6%A6%82%E8%A7%88糊昙，TXC模式和XA協(xié)議有點(diǎn)類似辛掠，主要原理如下：
Transaction Coordinator (TC)： 事務(wù)協(xié)調(diào)器，維護(hù)全局事務(wù)的運(yùn)行狀態(tài)释牺，負(fù)責(zé)協(xié)調(diào)并驅(qū)動(dòng)全局事務(wù)的提交或回滾萝衩。
Transaction Manager (TM)： 控制全局事務(wù)的邊界，負(fù)責(zé)開(kāi)啟一個(gè)全局事務(wù)没咙，并最終發(fā)起全局提交或全局回滾的決議猩谊。
Resource Manager (RM)： 控制分支事務(wù)，負(fù)責(zé)分支注冊(cè)祭刚、狀態(tài)匯報(bào)牌捷，并接收事務(wù)協(xié)調(diào)器的指令，驅(qū)動(dòng)分支（本地）事務(wù)的提交和回滾涡驮。
1.TM向TC申請(qǐng)開(kāi)啟一個(gè)全局事務(wù)暗甥，全局事務(wù)創(chuàng)建成功，并生成一個(gè)全局唯一的xid;
2.xid在微服務(wù)的調(diào)用鏈上下文中傳播捉捅；
3.RM向TC注冊(cè)分支事務(wù)撤防，將其納入XID對(duì)應(yīng)的全局事務(wù)的管轄中；
4.TM向TC發(fā)起針對(duì)XID的全局事務(wù)的提交或者回滾決議锯梁；
5.TC調(diào)度XID下管轄的全部分支事務(wù)來(lái)完成事務(wù)的提交或者回滾即碗。
TXC模式極大的減少了分支事務(wù)對(duì)資源的鎖定時(shí)間，提高了并發(fā)的性能陌凳。
5.LCN模式
LCN模式是通過(guò)代理Connection的方式實(shí)現(xiàn)對(duì)本地事務(wù)的操作剥懒，然后在由TxManager統(tǒng)一協(xié)調(diào)控制事務(wù)。當(dāng)本地事務(wù)提交回滾或者關(guān)閉連接時(shí)將會(huì)執(zhí)行假操作合敦，該代理的連接將由LCN連接池管理初橘。詳見(jiàn)：https://www.txlcn.org/zh-cn/docs/principle/lcn.html
該模式對(duì)代碼的嵌入性低，僅限于本地存在連接對(duì)象且可通過(guò)連接對(duì)象控制事務(wù)的模塊充岛。缺陷在于代理的連接需要隨事務(wù)發(fā)起方一共釋放連接保檐，增加了連接占用的時(shí)間。
參考：
https://www.cnblogs.com/zengkefu/p/5742617.html
https://www.txlcn.org/zh-cn/docs/preface.html
https://blog.csdn.net/ggibenben1314/article/details/48812501
https://github.com/alibaba/fescar/wiki/%E6%A6%82%E8%A7%88
