前言

---

?相關系列

• 《分布式 & 目錄》
• 《分布式 & 分布式事務 & 總結》
• 《分布式 & 分布式事務 & 問題》
  ?
  ?

分布式事務

---

????所謂分布式事務是指操作范圍籠罩多個不同節點的事務。例如對于訂單節點&庫存節點而言，一次完整的交易需要同時調動兩個節點。而如果將這個交易的所有操作作為ACID事務執行，那么該事務就被稱為分布式事務。
?
?

2PC @ 2 Phase Commit @ 二階段遞交

---

????2PC&3PC協議是處理分布式事務數據一致性（與CAP理論的一致性不同，事務的一致性是指確保數據在兩個“合法”狀態間的“正確轉移”）問題的解決方案，其本質是通過確保事務的原子性來保證一致性。在分布式系統中，節點雖然可以知曉自身操作的成功與否，但卻無法知曉其他節點操作的執行結果。因此當事務跨越多個節點時，為了保持事務的原子性&一致性，需要引入了TM @ 事務管理器來統一掌握所有RM @ 資源管理器的操作結果，并決定是否把各資源管理器的操作結果統一提交/回滾。2PC協議分為準備&提交兩個階段：

• Prepare phase @ 準備階段：事務管理器會向所有資源管理器發送（2PC/3PC/TCC協議都只是分布式事務的實現思想，因此事務管理器對資源管理器的請求發送無需在意串/并行，但具體的實現工具/框架就必須考慮這一點，因為各個資源管理器事務之間可能存在依賴性，例如事務B的執行需要事務A的執行結果參與）“準備”請求以確認其是否已準備好遞交事務。資源管理器在收到“準備”請求后會開啟&執行本地事務，但并不真正遞交，而是將Undo和Redo日志寫入本地事務日志中。Undo日志用于記錄如何回滾事務，而Redo日志則用于在提交階段重新執行事務操作。盡管在2PC中通常不直接使用Redo日志提交，但它在某些故障恢復場景中是有用的。本地事務執行結束后，將成功與否以Yes/No的形式回應至事務管理器；
• Commit phase @ 遞交階段：如果事務管理器收到所有反饋且發現資源管理器都已成功執行本地事務則會決定提交事務，否則就回滾事務。各節點在收到事務管理器發送的“遞交/回滾”請求后會統一將各自的執行結果遞交/回滾。

?

缺點

• 同步阻塞：在整個分布式事務未結束前，所有資源管理器（的事務涉及業務）都會處于阻塞狀態；
• 單點故障：事務管理器是整個分布式事務的核心，如果事務管理器宕機，那么所有資源管理器都會被鎖定而無法繼續執行；
• 數據不一致：二階段如果出現網絡分區/節點宕機而導致部分資源管理器未收到事務遞交指令/事務遞交失敗，那么就會出現數據不一致的情況。
  ?
  ?

3PC @ 3 Phase Commit @ 三階段遞交

---

????3PC協議在2PC協議的基礎上引入了檢查/超時機制，用于避免/處理2PC的“同步阻塞/單點故障/數據不一致”問題。3PC協議分為以下三個階段：

• CanCommit @ 可/詢問遞交：事務管理器向各資源管理器詢問是否可以支持執行/提交事務。各資源管理器接收到詢問后根據自身情況向事務管理器返回Yes/No回應。如果事務管理器沒有在指定時間內接收到所有回應/接收到No回應，則分布式事務中斷/取消。可/詢問遞交階段是3PC協議引入的新階段，目的是事先檢查資源管理器的狀態能否支持分布式事務的執行/遞交，從而避免無意義的分布式事務執行以增強協議的可靠性&容錯率；
• PreCommit @ 預提交：在接收到所有Yes回應的情況下，分布式事務會進入預遞交階段。該階段中事務管理器會向各資源管理器發送預遞交請求，而接收到請求的各資源管理器會開啟&執行本地事務但不遞交，并將Undo和Redo日志寫入本地事務日志中，隨后向事務管理器發送Ack回應。而如果事務管理器沒有在指定時間內接收到所有Ack回應/接收到Abort回應，則事務管理器會向各資源管理器發送Abort請求，從而令各資源管理器回滾本地事務。而在這階段中如果部分已開啟&執行本地執行的資源管理器未能在指定時間內接收到Abort請求，則其也會因為超時而自動回滾本地事務；
• DoCommit @ 最終提交：在接收到所有Ack回應后，分布式事務會進入最終遞交階段。該階段中事務管理器會向各資源管理器發送最終遞交請求，而接收到請求的各資源管理器會遞交事務，并向事務管理器發送Ack回應表示事務遞交已完成。注意！該階段中而如果有部分資源管理器未能在指定時間內接收到最終遞交請求，則該資源管理器就可能因為超時而自動回滾本地事務，從而無法保證分布式事務的原子性，并進一步破壞數據一致性。因此3PC協議同樣無法完全避免2PC協議的數據不一致問題。
  ?

優點

• 可靠性&容錯率提升：檢查機制增強了分布式事務的可靠性&容錯率；
• 超時機制減少了對阻塞時間：超時機制減少了資源管理器等待事務管理器指令的阻塞時間；
• 減少了單點故障對系統的影響：超時機制降低了事務管理器單點故障對系統的影響。
  ?

缺點

• 復雜性增加：3PC協議相比2PC協議而言需要處理更多狀態轉換&超時邏輯，這為增加了實現的難度&出錯的可能性；
• 性能開銷：更復雜的流程同步帶來了是性能開銷的增加；
• 數據不一致：3PC協議依然未能解決數據不一致問題，雖然檢查&超時有助于降低這一點，但網絡分區造成的數據不一致問題依然是存在的。
  ?
  ?

TCC @ Try Confirm Cancel @ 嘗試確認取消

---

????TCC協議是一種不同于2PC/3PC協議的分布式事務解決方案，其核心思想是“補償機制”，即在分布式事務出現異常/失敗時通過執行相反的操作來補償之前的行為，從而達到事務的一致性。TCC將分布式事務劃分為以下三個階段：

• Try @ 嘗試：事務管理器向事務協調器申請開啟分布式事務并獲得全局事務ID，隨后將該全局事務ID發送至各資源管理器。資源管理器接收到全局事務ID后會向事務協調器注冊分支事務ID，從而將分支事務ID納入該全局事務ID下管理。此后資源管理器便會開啟&執行本地事務并預留必要的資源，以便后續遞交事務時使用，并向事務管理器報告當前分支事務的開啟&執行情況；
• Confirm @ 確認：如果在嘗試階段中的所有的資源管理器都成功開啟&執行了本地事務，那么分布式事務就會進入確認階段。在確認階段中事務管理器會向各資源管理器發送確認請求，從而令其能夠真正的遞交事務，并于事務管理器中標記分支事務已成功遞交；
• Cancel @ 取消：如果在嘗試&確認階段中存在資源管理器未能成功開啟&執行&遞交本地事務的情況，那么分布式事務就會進入取消階段。在取消階段中事務管理器會向各資源管理器發送取消請求，從而回滾尚未遞交的事務/執行相反的操作彌補已遞交的事務，并于事務管理器中標記分支事務已成功取消。而對于因為各種原因未能接收到取消請求的資源管理器，由于超時機制的存在其也會自動執行取消行為，從而極大程度的確保了事務的原子性。
  ?

優點

• 極大確保了原子性：補償機制的存在使得已遞交的事務也可以被取消，從而降低因為網絡分區而數據不一致的風險；
• 避免數據庫鎖沖突的低性能風險：TCC通過將數據庫的二階段提交上升到微服務來實現，避免了數據庫二階段提交中鎖沖突導致的長事務低性能風險；
• 異步高性能：TCC采用了先try檢查，然后異步實現confirm的方式，提高了系統的性能和可擴展性。
  ?

缺點

• 侵入性強：微服務的每個事務都必須實現Try/Confirm/Cancel三個方法，增加了開發成本和后期維護改造的成本；
• 等冪性：為了達到事務的一致性要求，Try/Confirm/Cancel接口必須實現等冪性操作，這增加了實現的復雜性；
• 事務日志損耗性能：事務管理器需要記錄事務日志，這必定會損耗一定的性能，并可能使得整個TCC事務時間拉長。