5.1 TCC方案
TCC:Try、Confirm蹄葱、Cancel氏义。
Try階段:對各個服務(wù)的資源做監(jiān)測以及對資源進(jìn)行鎖定或者預(yù)留锄列。
Confirm階段:在各個服務(wù)中執(zhí)行實際的操作。
Cancel階段:如果任何一個服務(wù)的業(yè)務(wù)方法執(zhí)行出錯惯悠,那么這里就需要進(jìn)行補償邻邮,就是執(zhí)行已經(jīng)執(zhí)行成功的業(yè)務(wù)邏輯的回滾操作。
適用場景:大量的同步服務(wù)調(diào)用的復(fù)雜的事務(wù)場景吮螺,如果要用TCC來保證分布式事務(wù)的執(zhí)行饶囚,盡量確保每個服務(wù)的調(diào)用都比較快帕翻,確保一個TCC分布式事務(wù)的執(zhí)行鸠补,大概需要總共1秒以內(nèi)的時間。
常用框架:
1嘀掸、TX-LCN框架
2紫岩、tcc-transaction框架
https://github.com/changmingxie/tcc-transaction
3、himly框架
https://github.com/yu199195/hmily
4睬塌、ByteTCC框架
https://github.com/liuyangming/ByteTCC
5.2 本地消息表
適用場景:業(yè)務(wù)數(shù)據(jù)量不大的情況泉蝌。
5.3 可靠消息最終一致性方案
適用場景:適合比較耗時的操作,通過這個消息中間件做成異步調(diào)用揩晴,發(fā)送一個消息出去勋陪,人家服務(wù)消費消息來執(zhí)行業(yè)務(wù)邏輯。
可用RocketMQ的分布式事務(wù)實現(xiàn)可靠消息最終一致性方案硫兰。(RocketMQ = 可靠消息服務(wù)+MQ)
5.4 最大努力通知方案
適用場景:跟可靠消息最終一致性方案類似诅愚,可靠消息最終一致性方案,會保證最終必須要讓那個執(zhí)行成功的劫映,但是最大努力通知方案违孝,不一定保證最終一定會成功,可能會失敗泳赋,但是會盡力給你去給你通知那個服務(wù)的執(zhí)行雌桑。
5.5 saga事務(wù)
saga事務(wù):saga是將每個接口,拆分為2個接口祖今,一個是業(yè)務(wù)接口校坑,另外一個是補償接口,相當(dāng)于就是說將tcc里面的try和confirm合并為一個接口千诬,就是先執(zhí)行業(yè)務(wù)接口耍目,直接就嘗試完成整個業(yè)務(wù)邏輯的操作。然后如果在服務(wù)調(diào)用鏈條里面大渤,某個服務(wù)的業(yè)務(wù)接口執(zhí)行失敗了制妄,那么直接對已經(jīng)執(zhí)行成功的所有服務(wù)都調(diào)用其補償接口,將之前執(zhí)行成功的業(yè)務(wù)邏輯給回滾。
saga事務(wù)的核心和本質(zhì):就是把每個操作分為實際的業(yè)務(wù)邏輯以及補償業(yè)務(wù)邏輯赡茸,正常情況下更振,就依次執(zhí)行各個服務(wù)的業(yè)務(wù)邏輯就好了颠猴,如果某個服務(wù)調(diào)用失敗的話顶燕,直接對之前執(zhí)行成功的那些服務(wù)都依次執(zhí)行補償邏輯若未。
saga事務(wù)的思想:就是將一個長的分布式事務(wù)辐真,拆分為一連串的每個服務(wù)的本地事務(wù)糕珊,然后每個服務(wù)對每個接口提供兩個接口磷斧,一個是業(yè)務(wù)接口振愿,一個是回滾的補償接口,正常情況下就是依次的進(jìn)行調(diào)用弛饭。異常情況下冕末,就對之前已經(jīng)執(zhí)行成功的服務(wù)執(zhí)行補償接口,回滾業(yè)務(wù)邏輯侣颂。