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ù)邏輯侣颂。
