分布式事務基本概念
使用分布式事務的場景：分布式場景下的跨數據庫事務
分布式事務誕生的理論：CAP和Base
3種一致性：
強一致性 ：系統寫入了什么，讀出來的就是什么。
弱一致性 ：不一定可以讀取到最新寫入的值，也不保證多少時間之后讀取到的數據是最新的，只是會盡量保證某個時刻達到數據一致的狀態。
最終一致性 ：弱一致性的升級版。系統會保證在一定時間內達到數據一致的狀態
其他一致性：
讀寫一致性：是一種在分布式系統中保證讀取操作與寫入操作之間一致性的模型
柔性事務（最終一致性）：TCC、 Saga、MQ 事務 、本地消息表補償
剛性事務（強一致性）：2PC，3PC
剛性事務是基于數據庫層面保證事務的強一致性的，柔性事務是基于外部中間件或者代碼保證事務的最終一致性的
業務代碼侵入方案：TCC，Saga
業務代碼無侵入方案：2PC，3PC
XA規范的角色：
Application Program ：AP，應用程序本身
Resource Manager ： RM，資源管理器，指的是數據庫
Transational Manager ：TM，事務管理器
2PC-兩階段提交
2PC的執行流程：
分為準備階段和提交階段
準備階段：詢問RM是否能執行事務，如果能執行事務就直接做預處理，例如Mysql的預處理就是寫入Undo日志和Redo日志，但是不寫入Binlog日志，因為此時事務還沒提交
提交階段：查看所有的RM是否預處理成功（全部RM屬于就緒狀態），如果全部成功就提交，如果有一個失敗了就回滾
2PC的優缺點：
優點：
- 簡單
- 數據強一致性
缺點：
- 同步阻塞，要等待所有事務都就緒再提交
- 部分數據不一致情況，commit和rollback不能保證所有節點同時成功
- 沒有超時機制，TM掛掉后多個RM的事務會一直等待提交
3PC-三階段提交
3PC的執行流程：
準備階段，預提交階段，提交階段
準備階段：詢問RM是否能執行事務，超時或者RM說不能執行事務就中斷事務
預提交階段：再一次詢問RM是否能執行事務，如果可以就進入預提交（寫入Undo日志和Redo日志），如果No或者超時就回滾
提交階段：所有RM都預處理成功，則提交事務。有一個RM失敗或者超時了，則回滾
2PC對比3PC：
- 3PC是多次判斷數據庫狀態（多了一次判斷），加入了新的協議，同時增加了通信的開銷
- 3PC引入的RM超時機制是多次一舉的，其實2PC就夠了，2PC的RM一直等待的情況其實是理論而已，實際Mysql等數據庫本身就有事務超時機制
- 2PC實現更加簡單
- 3PC不僅沒有完全解決阻塞問題還會導致性能更糟糕，多數應用會選擇通過復制狀態機解決 2PC 的阻塞問題
TCC補償事務
TCC的執行流程：
Try，Confirm，Cancel
執行流程：Try，Try成功就Confirm，失敗就Cancel
TCC會將日志記錄，實戰中會實現Confirm失敗和Cancel失敗的情況，會進行重試，如果重試多次失敗要走人工補償
TCC和2PC的區別：
- TCC是基于代碼自定義邏輯來補償保證最終一致性，2PC是基于Mysql事務保證強一致性
- TCC的Try是類似于凍結，例如500元轉賬100元是凍結這個100元而不是真的轉賬。而2PC是給這500元的記錄上記錄鎖
- 業務補償邏輯的區別，TCC不是基于數據庫的通用事務機制，而是根據具體業務的流程和規則編寫的代碼
TCC和2PC，3PC的區別：
- 2PC/3PC 依靠數據庫或者存儲資源層面的事務，TCC 主要通過修改業務代碼來實現。
- 2PC/3PC 屬于業務代碼無侵入的，TCC 對業務代碼有侵入。
- 2PC/3PC 追求的是強一致性，在兩階段提交的整個過程中，一直會持有數據庫的鎖。TCC 追求的是最終一致性，不會一直持有各個業務資源的鎖
MQ事務
RocketMQ和Kafka都提供了事務的相關功能
可以將生產消息，消費，處理整個過程變成一個原子性的操作
Saga事務
長事務分為多個短事務，然后短事務分別按順序提交，有一個短事務失敗就回滾
失敗的補償邏輯還是要通過業務代碼補償
正向補償的執行順序（失敗回滾）：T1，T2，…，Ti（失敗），Ci（補償），…，C2，C1
反向補償的執行順序（失敗重試）：T1，T2，…，Ti（失敗），Ti（重試）…，Ti+1，…，Tn。
