分布式事務，還是 上面 A，B,C 的例子
但是 A，B ，C是 3 個獨立的程序了， A ，B，C中 不是本地調用，而是 RPC 調用（ 不管是 什麽RPC 都是走的網絡 ，不是本地調用（指的本程序內，不需要過網絡 ，不過需要過IP地址 ）），
這時候本地事務明顯不生效了。
在來模擬 服務的 A 方法裏面調用了 ，B服務的 B方法，然後調用的 C服務的 C方法。
然後，
1 如果 A 調用 B ，C 之前報錯，A 被事務回滾 ，B ，C 沒有調用， 這沒問題。
2 如果是 A 調用 了 B，C 以後 A 拋出異常， 那麽 A 回滾了 ，B ，C 執行了 就提交了。 數據 不壹致了
3 如果 A 調用 B ，然後調用 C ，C 報錯了 ，C 回滾，C 調用異常 被 A 感知，A 也會回滾，B 執行完就自己提交了，不會跟著壹起回滾，數據不壹致。
有人會說 我避免 3 個服務相互調用 ，我每次 只有2 個服務相互聯系
我 只會 A 調用 B ，然後 B 調用C
1 A 調用 B ，在方法的最後面 ，A 前面如果報錯 了，B不會被調用 ，如果前面沒有出錯 ，調用B，B失敗了，B回滾，異常傳遞個A，A 也回滾 ， A B 之間的數據就 壹致了 ，B,C 同理。
上面說的沒錯，理想環境下，如果只保持 2 層調用，並且調用 下壹個服務 都在 事務提交前壹刻執行 那麽完全沒問題，但是 網絡環境 有壹種極端情況。
A 發起壹次調用B 可以拆分成幾部，A請求B ---> B 收到請求 做自己的 ---> 然後B 響應 A --> A 收到 B 的響應
這時候 如果 B做了，提交了自己， 然後響應B的時候超時， A 那邊拋出響應超時， A 不知道 B 是 做了 還是 沒做 ，A 收到 超時異常 就回滾，然後 數據就不壹致了。
有人又說了，我們是是內網 無限帶寬 幾乎不會出絡異常，不考慮。網絡不考慮，但是如果 B 做了提交了事務，然後B掛了，A 依舊沒有收到響應，依舊要回滾，還是 會出數據不壹致的問題。即便這些都是 小概率，然後 服務 只能保持 2 層調用，在大型 系統中依舊 明顯不適用 ，因為這樣會 鏈 會很長，調用會很不方便，然後 這個 鏈還必須是同步執行的。效率差。
解釋 分布式環境 為什麽會出 壹致性問題，所以分布式事務就是來解決這些問題的。
分布式事務 在我看來有4種
第1種 2pc事務,3pc事務，包括 TX-LCN 的 LCN 模式， 可以叫做 長鎖定多段式分布式事務
第2中 TCC 這種補償事務， 可以叫做短鎖定多段式分布式事務，特地額 try 階段 會獨立提交，不會多個節點相互 等待，comfrom 階段 也是相互獨立的。 比第壹種效率高，但是 壹個方法寫三遍，壹個邏輯 分三個方向寫，編碼麻煩。
第3中，基於消息：效率沒有 長鎖定多段式分布式事務 那麽低， 編碼沒有 TCC 那麽麻煩。 但是需要註意的編程細節也挺多的。 總的來說算壹種比較綜合的解決方案，消息機制 有個 很明顯的缺陷，它強調保證最終壹致性，並不能同時回滾。 A 服務 發送給B服務的的消息,或者發出去的確認消息，只能完成， B 做失敗了，只能重試（並且保持冪等）， 不能讓 A 壹起回滾。 只有 主動 發起方可以終止 和回滾 這個分布式事務，入股A 提交以後，只能硬著頭皮走到底。