分散式事務，算是分散式系統極為重要的一個模組。
分散式事務的概念，網上隨手可見，我不多講。
今天主要想聊聊，分散式事務的解決思路及其適用場景。
在說具體思路之前，我先假設一個業務排程功能，分別會呼叫A、B、C三個服務。
要保證這三個服務的事務，該怎麼辦呢？
可靠訊息佇列
A業務完成並提交資料庫事務後，傳送訊息；B收到訊息後，完成業務並提交資料庫事務後，傳送訊息；
C收到訊息後，完成業務並提交資料庫事務。
整個過程，要保證盡一切可能完成，極端情況甚至需要人工介入。
優點：系統效能好（無需資料庫鎖）。
缺點：只能保證最終一致性，且可能需要人工介入。
適用場景：比如支付公司，交易和清分，便很適合透過可靠訊息佇列來實現，能極大提升交易介面效能。
XA
透過資料庫事務來實現。
優點：真正的資料庫級別事務。
缺點：效能低。若A、B、C跨公司，則完全無法實現。
TCC
分為Try、Commit、Cancel兩個階段
先預留業務資源，成功則Commit，失敗則Cancel。
優點：效能高。
缺點：實現複雜，容易出錯。且有些業務無法預留業務資源。
適用場景：透過賬戶交易下單類業務。比如將錢充值到加油App後，
透過App賬戶加油。（這個業務，必須先加油，再扣錢，所以必須鎖住賬戶餘額）
AT
A、B、C分別執行並提交本地資料庫事務，當失敗時，執行逆向SQL。這個方案，需要藉助框架，逆向
SQL是框架自動生成且由框架自動執行。
優點：效能高，業務端實現簡單。
缺點：由於沒有預留業務資源，可能導致資源無法回收。
適用場景：公司內部系統，跨公司系統無法使用。
SAGA
業務編排 + 反向補償，反向補償又分為實時補償和定時補償。
優點：效能高，跨公司事務也能支援。
缺點：可能出現業務無法補償的情況，所以對業務編排有要求。
適用場景：跨公司類的長事務業務。