一、分布式事務(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