3、落地方案
4、總結
孫玄；擅長系統架構設計，大資料，運維、機器學習等技術領域；代表公司多次在業界頂級技術大會 cio針對分布式系統的特點，基於不同的一致性需求產生了不同的分布式事務解決方案，追求強一致的兩階段提交、追求最終一致性的柔性事務和事務訊息等等。各種方案沒有絕對的好壞，拋開具體場景我們無法評價，更無法能做出合理選擇。在選擇分布式事務方案時，需要我們充分了解各種解決方案的原理和設計初衷，再結合實際的業務場景，從而做出科學合理的選擇。峰會、artificial、intelligence、conference、a2m、qcon、archsummit、sacc、sdcc、cctc、dtcc、top100、strata
+、hadoop world、wot、gitc、giac、tid等發表演講，並為《程式設計師》雜誌撰稿 2 篇。
兩階段提交演算法中有兩種角色：事務協調者和事務參與者，乙個事務一般會涉及多個事務參與者，具體的兩階段過程如下圖所示：
第一階段：寫庫操作完成後協調者向所有參與者傳送prepare訊息，詢問各參與者的本地事務是否可以提交，參與者根據自身情況向協調者返回可以或不可以；
第二階段：協調者收到所有參與者的反饋後，如果全部返回的是可以提交則向所有參與者傳送提交事務命令。只要有乙個參與者返回的是不能提交，則向所有參與者傳送回滾命令。如下圖所示：
在上述的兩階段模型中，事務提交過程中有可能出現協調者或個別參與者宕機的情況，但多數情況下參與事務的節點可以通過詢問其他節點得知事務狀態，做出正確的操作。但在極端情況下事務有可能處於未知狀態。我們分析下下面這個場景：當協調者傳送提交指令後宕機，而唯一收到提交指令的參與者完成提交後也宕機了，此時沒有節點知道事務應該提交還是回滾，事務處於未知狀態，所以在這種極端情況下可能造成資料的不一致。針對兩階段的缺陷，又提出了三階段提交協議。
三階段提交是將第二階段拆分成預提交和確認提交兩個階段。這樣在事務提交過程中，無論哪個節點宕機，只要有乙個存活節點處於預提交或是提交狀態我們都可以確定事務是可以提交的（第一階段已經確認事務可以提交），反之如果沒有處於這兩種狀態的節點，則回滾事務。
從上面的分析可以看到，無論是兩階段還是三階段最後的「提交」都是乙個耗時極短的操作，即使在分布式系統中失敗的概率也是非常小的，所以我們可以認為兩階段提交基本能夠保證分布式事務原子性。
上面介紹的只是理論基礎，xa規範就是基於兩階段提交的理論模型提出的分布式事務規範，規範中的資源管理器相當於事務參與者；事務管理器相當於事務協調者，目前很多主流的關聯式資料庫都實現了xa介面。
落地到實際應用中我們會發現兩階段提交存在的一些問題：
資料庫產品要保證資料完成性，寫入需要加鎖，所以在整個分布式事務協調過程中可能造成資料庫資源鎖定時間過長，不適合併發高以及子事務生命週期較長的業務場景；
xa 規範要求事務管理器本地記錄事務執行狀態，所以事務管理器作為有狀態服務不支援事務異地恢復；
xa 能夠最大程度保證資料的一致性，但在高併發場景下效能衰減非常嚴重，所以在資料一致性需求上如果不是「強一致」，不建議使用。
在我們大多數的業務場景中，追求的都是資料的最終一致性，業界也提出了很多柔性事務的解決方案，可以很大程度上保證資料的一致性，我們可以根據實際場景來權衡使用。具體的解決方案有很多，總結其設計思路可以分為下面 3 種模型：
tcc 將事務分為 try，confirm，cancel 三個階段。
try 階段：嘗試執行業務，預留資源；
confirm 階段：確認執行業務，使用 try 階段資源；
cancel 階段：取消執行業務，釋放 try 階段預留的資源；
我們用乙個轉賬匯款的業務場景，說明下 tcc 的具體過程。例如：張三給李四轉賬 100 元，一次轉賬業務由兩個本地事務組成：1、張三賬戶扣減 100 元；2、李四賬戶增加 100 元。
事務成功處理流程如圖 3：
事務失敗處理流程如圖 4：
try 階段：
1、檢查張三賬戶，滿足要求賬戶扣減 100元，記錄扣減事件（預留資源）；
2、檢查李四賬戶有效性；
如果 try 成功，李四賬戶增加 100 元，事務完成；如果 try 失敗，張三賬戶增加 100 元，刪除扣減事件記錄（釋放預留資源），事務取消。需要有類似事務管理器的角色保證 tcc 過程的完整性；
confirm 和 cancel 方法需要保證冪等（由於不可避免的重試操作必須要保證冪等）；
tcc 對業務侵入非常大，對 rd 同學十分不友好，業務改造成本相當高。
saga 模型把乙個分布式事務拆分為多個本地事務，每個本地事務都有相應的執行模組和補償模組，當事務中任意乙個本地事務出錯時，可以通過呼叫對應的補償方法恢復之前的事務，從而達到資料的最終的一致性。saga 的事務管理器負責在事務失敗時執行補償邏輯，可以通過呼叫執行模組的逆向操作（例如執行子事務時同時生成逆向 sql）或呼叫業務開發人員提供的補償方法（需要保證補償的冪等性）來實現。
可以看到，saga 雖然對業務造成一定的侵入，但當相對 tcc 已經有好很多了，而且，事務管理器理論上可以做到向後補償（撤銷所有已完成操作，恢復到事務開始狀態）或向前補償（繼續完成未完成事務，使業務請求得到成功處理，更符合業務預期）。
mq 事務訊息對分布式事務模型進行了簡化，重點不再是保證所有子事務的原子性，而是保證本地事務和傳送 mq 訊息的原子性，我們可以利用這一特點，將分布式事務轉化成本地事務和若干傳送 mq 訊息的操作，然後要求消費方確保消費成功。利用 mq 事務訊息，在系統中去掉了 tcc 和 saga 方案中的事務管理器角色，簡化了分布式事務模型，同時這也是對業務侵入最低最友好的方案（不用提供補償介面）。
當然這裡也有兩個基本前提：
mq 系統保證訊息能不丟失；
消費方確保消費冪等（保證不丟失，就很難避免重複消費）。
需要注意的是，mq 事務訊息簡化了事務模型、降低了業務侵入，所以對資料一致性的保證保障也就相對比較低了。
柔性事務解決方案中，雖然 saga 和 tcc 看上去可以保證資料的最終一致性，但分布式系統的成產環境複雜多變，某些情況是可以導致柔性事務機制失效的，所以無論使用那種方案，都需要最終的兜底策略，人工校驗，修復資料。
我們綜合對比下幾種分布式事務解決方案：
一致性保證：xa > tcc = saga > 事務訊息最後，在設計系統時我們一定要結合業務自身的一致性需求，選擇恰當的方案。可以看到對資料一致性保障越高的方案其開發成本、維護難度和系統效能損耗就越大，一定不要一味的追求高大上的方案，對系統過度設計。業務友好性：xa > 事務訊息 > saga > tcc
性 能 損 耗：xa > tcc > saga = 事務訊息
關注【架構之美】，與孫玄老師**更多深層次架構知識
分布式事務實現思路
大體思路是對事務進行 手動控制事務的開啟提交。datasource connect transaction transtaction註解也是aop 自己編寫事務註解zdytranstaction實現transtration裡面的幾個方法，connect也是，對datasource connect t...
分布式事務 金融業微服務實踐案例
在網易雲輕舟微服務平台中，我們的微服務框架除了完成一些基本事項 比如熔斷 限流 降級 彈性伸縮等 也開發了很多符合行業特性的定製化產品。這是因為我們發現傳統行業與網際網路行業的經營模式有著很大的不同，不同客戶的關注點並不一樣，架構師想要用乙個產品把以上專案全部覆蓋還是比較困難的。但是，我們可以根據客...
微服務架構分布式事務解決方案 FESCAR
fescar fast easy commit and rollback 是乙個用於微服務架構的分布式事務解決方案，它的特點是高效能且易於使用，旨在實現簡單並快速的事務提交與回滾。微服務架構中的分布式事務問題 從傳統的單體應用說起，假設乙個單體應用的業務由 3 個模組構成，三者使用單個本地資料來源。...