近期公司項目基於微服務架構需要涉及到實現一套分佈式事務。經過幾天在網上查閱資料發現大部分文章只是講解了具體的其中一個模型。因此在這裏做一個總結+自己的一些感悟和看法。
1.CAP理論
CAP理論本身並不是一套和事務相關的理論，而是用來解釋分佈式系統的理論。但是用來分析分佈式事物的邊界非常適合。關於CAP理論，可以查看阮一峯大神的這篇文章：CAP定理的含義
CAP理論一個核心論證就是P(分區容錯性)作爲一個分佈式系統是肯定包含的。因此實際實現只是在CP和AP之間做抉擇。
CP：爲了保證一致性和分區容錯性，那麼肯定會喪失一部分可用性。
AP：爲了保證可用性和分區容錯性，那麼肯定會喪失一部分一致性。
2.ACID原則
ACID原則是用來描述一個事務應該包含的特性。原子性、一致性、隔離性、持久性。這個原則實際上和CAP理論是相悖的。
3.剛性事務、CP模式、XA協議
我們來假設一個簡單的支付場景，生成訂單--->扣用戶積分--->覈銷優惠劵--->修改訂單狀態。這裏涉及三個系統，訂單系統、用戶積分系統、優惠劵系統。那麼如果我們要保證事務的一致性，我們在其中的每一步都會將資源鎖定，然後只有在最終事務全部完成後，我們才能釋放鎖。那麼在整個事務週期內我們的功能必定是處於不可用狀態。這也正符合CP定義。這麼做的事務確實可以保證事務的ACID原則，但是因爲鎖定時間長、鎖粒度大(鎖定資源多)，在高併發的情況下，並不適用。這一類強一致性事務，稱爲剛性事務。
Mysql在5.6之前就支持了XA協議，允許使用剛性事務。當然Mysql僅僅是支持了協議，提供了接口。XA協議中的2PC(2階段提交)模型中的全局管理者和參與者還是需要自己實現。
4.柔性事務、AP模式、TCC模型、消息事務模型
剛性事務既然不符合常用的場景，那麼我們就只能犧牲一部分一致性，保證最終一致性。也就是BASE理論基本可用、軟狀態、最終一致性。這一類事務稱爲柔性事務，常見的模型有兩類，TCC模型：try-confirm-cancel。基於消息系統的實現：最大努力通知型、可靠消息型。
5.真的需要分佈式事務嗎？
在真正的開始使用、實現分佈式事務前，我們先要確定自己的需求真的需要一個分佈式事務纔可以實現嗎？依然是之前的場景：生成訂單--->扣用戶積分--->覈銷優惠劵--->修改訂單狀態。
整個流程都是同步調用，那麼作爲下一個步驟的發起方總是能獲取被動方執行的結果。如果其中任何一個被動方報錯，那麼只需要上一步一步的回滾就可以了。
當然其中的每一步都是一個局部本地的事務，執行下一步操作之前，當前的本地事務肯定是已經完成了，那麼回滾當然不能簡單的rollback()就可以了。其實可以每一個步驟實現一個回退的接口。當出現需要回滾的情況時候，由最上層的發起方依次調用指定服務的回退接口就可以了。
這種實現實際上完全BASE理論，從出現問題到全部回滾完之前的中間狀態下，數據確實是不一致的，但是回滾之後就是符合最終一致性的。根據前文所說的CAP理論，在分佈式系統下你是不可能保證數據的強一致性的！！！。因此，如果你使用分佈式事務是簡單的任務能滿足強一致性，推薦你使用剛性事務實現。
6.同步場景下柔性事務還有意義嗎？
通過之前的分析，其實同步場景下只需要通過上層調用實現的回滾接口就可以避免使用分佈式事務，那麼這種柔性事務還有什麼意義呢？所謂的TCC模型、消息模型還有什麼意義呢？我的理解是雖然同步調用情況下可以通過前文所說避免柔性事務，但是還是可能有完全不一致的情況出現。
首先就是上層調用方直接掛掉了。整個調用鏈斷掉了。這種情況下當然可以通過監控、校對來進行干預。
第二種情況我認爲就是對代碼結構的封裝了，如果每一個類似的調用鏈都需要開發者自己去手動判斷+調用回滾，容易遺漏、出錯，並且破壞代碼結構。這種情況下使用一個統一的分佈式事務將事務間的關聯管理起來，回滾等操作都調用方來說都不透明似乎是一個很好的選擇。