結合多篇文章和實踐，總結一下分布式事務相關的內(nèi)容。
分布式事務是什么
百度百科的說法
分布式事務是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點之上。
分布式事務首先是一種事務，需要提供事務具有A（原子性）C（一致性）I（隔離性）D（持久性）四大特性。其次它是分布式的，涉及到多個不同子系統(tǒng)之間的交互，在這樣復雜的情況下實現(xiàn)事務功能。
為什么需要分布式事務
需要在多個子系統(tǒng)交互完成一件事情的時候，如果不實現(xiàn)分布式事務，會導致事情完成情況出現(xiàn)各種不確定的因素，正常可能大部分都是成功，有一部分會出現(xiàn)失敗和未知的情況，從而導致數(shù)據(jù)不一致。如果涉及到資金，可能會導致客戶和公司產(chǎn)生巨大損失。因此需要分布式事務來保證數(shù)據(jù)的一致性。
分布式事務實現(xiàn)方式
分布式事務經(jīng)過很長時間的演進，有很多種實現(xiàn)，每一種實現(xiàn)都有不同的使用場景。
2PC
2PC叫做兩階段提交，思路是事務參與者將操作成敗通知事務協(xié)調(diào)者，再由事務協(xié)調(diào)者根據(jù)所有事務參與者的反饋情報決定各事務參與者是否要提交操作還是中止操作。
?
其中事務參與者也叫做資源管理器，事務協(xié)調(diào)者也叫做事務管理器。資源管理器（RM, resource manager）需要提供“準備”、“提交”和“回滾” 3 個操作；而事務管理器（TM, transaction manager）分 2 階段協(xié)調(diào)所有資源管理器。
缺點
- 同步阻塞問題
- 協(xié)調(diào)者不可靠
3PC
3PC叫做三階段提交，三階段提交是對二階段提交的改進。三階段提交在兩階段提交的第一階段與第二階段之間插入了一個準備階段，使得原先在兩階段提交中，事務參與者在投票之后，由于事務協(xié)調(diào)者發(fā)生崩潰或錯誤，而導致事務參與者處于無法知曉是否提交或者中止的“不確定狀態(tài)”所產(chǎn)生的可能相當長的延時的問題得以解決。
?
TCC
TCC（Try-Confirm-Cancel）是資源管理器的一種服務化的實現(xiàn)， Try、Confirm、Cancel 3 個方法均由業(yè)務編碼實現(xiàn)，故 TCC 可以被稱為是服務化的資源管理器。
TCC 的 Try 操作作為一階段，負責資源的檢查和預留；Confirm 操作作為二階段提交操作，執(zhí)行真正的業(yè)務；Cancel 是二階段回滾操作，執(zhí)行預留資源的取消，使資源回到初始狀態(tài)。
?
要點
- 空回滾
- 防懸掛
- 冪等
基于消息隊列的事務
?
前提條件就是，異步執(zhí)行的那部分操作，不能有依賴的資源。比如說，我們下單的時候，除了要清空購物車以外，還需要鎖定庫存。
Saga
一個Saga事務就是一個長期運行的事務，這個事務是由多個本地事務所組成， 每個本地事務有相應的執(zhí)行模塊和補償模塊，當Saga事務中的任意一個本地事務出錯了， 可以通過調(diào)用相關事務對應的補償方法恢復，達到事務的最終一致性。
適用場景：
- 業(yè)務流程長、業(yè)務流程多
- 參與者包含其它公司或遺留系統(tǒng)服務，無法提供 TCC 模式要求的三個接口
優(yōu)勢：
- 一階段提交本地事務，無鎖，高性能
- 事件驅動架構，參與者可異步執(zhí)行，高吞吐
- 補償服務易于實現(xiàn)
缺點：
- 不保證隔離性
實踐
Seata實踐
Seata 是一款開源的分布式事務解決方案，致力于在微服務架構下提供高性能和簡單易用的分布式事務服務。
Seata的精華在于對業(yè)務的非侵入性，事務與業(yè)務分離，客戶可以聚焦于業(yè)務開發(fā)。
性能方面，SEATA架構可以支撐10萬tps以上。
高可用方面，任一節(jié)點故障可以做到秒級恢復。
?
TC (Transaction Coordinator) - 事務協(xié)調(diào)者負責維護全局和分支事務的狀態(tài)，驅動全局事務提交或回滾。
TM (Transaction Manager) - 事務管理器負責定義全局事務的范圍：開始全局事務、提交或回滾全局事務。
RM (Resource Manager) - 資源管理器負責管理分支事務處理的資源，與TC交談以注冊分支事務和報告分支事務的狀態(tài)，并驅動分支事務提交或回滾。
Seata 與其它分布式最大的區(qū)別在于，它在第一提交階段就已經(jīng)將各個事務操作 commit 了。
Seata 認為在一個正常的業(yè)務下，各個服務提交事務的大概率是成功的，這種事務提交操作可以節(jié)約兩個階段持有鎖的時間，從而提高整體的執(zhí)行效率。
那如果在第一階段就已經(jīng)提交了事務，那我們還談何回滾呢？
Seata 將 RM 提升到了服務層，通過 JDBC 數(shù)據(jù)源代理解析 SQL，把業(yè)務數(shù)據(jù)在更新前后的數(shù)據(jù)鏡像組織成回滾日志，利用本地事務的 ACID 特性，將業(yè)務數(shù)據(jù)的更新和回滾日志的寫入在同一個本地事務中提交。如果 TC 決議要全局回滾，會通知 RM 進行回滾操作，通過 XID 找到對應的回滾日志記錄，通過回滾記錄生成反向更新 SQL，進行更新回滾操作。
以上我們可以保證一個事務的原子性和一致性，但隔離性如何保證呢？
Seata 設計通過事務協(xié)調(diào)器維護的全局寫排它鎖，來保證事務間的寫隔離，而讀寫隔離級別則默認為未提交讀的隔離級別。
具體實踐可以查看下面Spring Cloud Alibaba集成的示例
TCC實踐的業(yè)務流程圖
國內(nèi)開源TCC框架：ByteTCC，TCC-transaction，Himly
?
?
最佳實踐和參考資料
- http://seata.io/zh-cn/blog/tcc-mode-design-principle.html
- https://www.cnblogs.com/jajian/p/10014145.html
- http://seata.io/zh-cn/blog/tcc-mode-applicable-scenario-analysis.html
這篇文章講述了TCC事務實現(xiàn)方式在不同的業(yè)務場景下的適配性，根據(jù)場景談實現(xiàn)方案真是最好的方式。
