分佈系統中，如何保證數據的一致性、原子性，分散式事務。分散式事務分為兩大類，柔性事務、剛性事務。 一、方法論篇 分散式事務主要分為兩部分，剛性事務和柔性事務。剛性事務主要針對DB層面，嚴格保證事務的原子性要麼都成功，要麼執行失敗，全部回滾。 柔性事務，相對於剛性事務來的，為了保證DB的利用率，以及系 ...
分佈系統中，如何保證數據的一致性、原子性，分散式事務。分散式事務分為兩大類，柔性事務、剛性事務。
一、方法論篇
分散式事務主要分為兩部分，剛性事務和柔性事務。剛性事務主要針對DB層面，嚴格保證事務的原子性要麼都成功，要麼執行失敗，全部回滾。 柔性事務，相對於剛性事務來的，為了保證DB的利用率，以及系統的吞吐量，不會長時間鎖定DB資源，在事務執行失敗之後不會進行回滾，而是採用補償的方式保證數據的最終一致性，所以柔性事務又叫補償型事務。先來介紹剛性事務。1.1剛性事務
X/Open XA 協議，最早的分散式事務模型是 X/Open 國際聯盟提出的 X/Open Distributed Transaction Processing（DTP）模型，也就是大家常說的 X/Open XA 協議，簡稱XA 協議。
名詞解釋：
- 其中應用程式(Application Program ，簡稱AP)：AP定義事務邊界（定義事務開始和結束）並訪問事務邊界內的資源。
- 資源管理器(Resource Manager，簡稱RM)：Rm管理電腦共用的資源，許多軟體都可以去訪問這些資源，資源包含比如資料庫、文件系統、印表機伺服器等。
- 事務管理器(Transaction Manager ，簡稱TM)：負責管理全局事務，分配事務唯一標識，監控事務的執行進度，並負責事務的提交、回滾、失敗恢復等。
操作過程
- 第一階段，AP發起事務，TM要求所有的RM準備提交對應的事務分支，詢問RM是否有能力保證成功的提交事務分支，RM根據自己的情況，如果判斷自己進行的工作可以被提交，那就就對工作內容進行持久化，並給TM回執OK；否者給TM的回執NO。RM在發送了否定答覆並回滾了已經的工作後，就可以丟棄這個事務分支信息了。
- 第二階段TM根據階段1各個RM prepare的結果，決定是提交還是回滾事務。如果所有的RM都prepare成功，那麼TM通知所有的RM進行提交；如果有RM prepare回執NO的話，則TM通知所有RM回滾自己的事務分支。
1.1.1 2PC
第一階段，資源預占階段（準備階段），所有RM回覆OK，則提交事務，否則失敗。
第二階段，事務提交階段（資源執行階段），所有執行成功則執行成功，否則返回失敗。
1.1.2 3PC
比2pc多一個階段，增一個CanCommit子階段不占有資源，提升性能。1.1.3 小結
剛性事務是一個阻塞性的事務（DB層面的一種定義）會占用，過多資源，併發度低，會導致吞吐量偏低。一般不建議在耗時較大的分散式事務中使用剛性事務。1.2柔性事務
就過程本質上也是2pc階段，只不過在應用層面實現減少對DB的持有時間，是一種補償型事務，事務執行失敗，進行補償，最終保證事務成功，而不做回滾。其實利用的Base理論，保證服務的基本可用，是CAP模型中AP模型的演化結果。 ba（base available）基本可用； s(soft state)中間狀態； e(eventual consistency)最終一致性的理論。1.2.1TCC
TCC（Try-Confirm-Cancel），期模型完全交由業務方實現，每個在業務中的子模塊都需要實現Try，Confirm，Cancel三個介面，對業務入侵極大。有原來的一個介面就實現完的內容現在需要二外的多增加兩個介面，開發量增加了兩倍。TCC讓應用程式自己定義資料庫操作的粒度，使得降低鎖衝突、提高吞吐量成為可能。
名詞解釋：
T（Try）:完成業務方面的檢查，預留相關的資源。假設一個業務完成需要A,B,C三個子事務完成，這時候需要調用A,B,C三個業務的Try介面。
C（Confirm）：成功預占資源（A,B,C三個Try都成功），真正的執行業務；
C（Cancel）：事務執行失敗（A,B,C三個Try只要有一個失敗），釋放Try階段的資源。
問題：超時如何處理？ 超時需要重試，所以介面實現介面需要冪登。1.2.2Saga
將try和confirm合成一個階段，cancel變成補償階段。接下來看一下官方定義：- 每個Saga將一個大的分散式事務拆分為若幹sub-transaction Ti
- 每個Ti 都有對應的補償動作Ci，補償動作用於撤銷Ti造成的結果
- 當Saga事務中的任何一個本地事務執行失敗之後，調用補償方法恢復之前的事務，達到最終一致
- 恢復的方式
- 事務特征：
- 不具有隔離性，需要業務方法控制併發，保證某個執行失敗的事務，所占有的資源不會業務上影響別的事務執行，
- 一致性：追中一致性
1.2.3TCC與Saga比較
TCC 缺點： 1、業務侵入性高，每一個本地事務都需要開發三個介面； 2、較原來與本地事務的交互次數多了一倍，較原來多了一個Confirm或者Cancel； 3、一旦進入Confirm階段必須保證成功，不成功需要人工接入； 優點： 資源通過Try提前占用，數據能得到較好的隔離； Sage 優點： 1、性能開銷較小，在執行成功的情況下只需要一次交互； 2、對現有業務侵入性小，現有業務幾乎不需要改變，只需要增加補償介面； 缺點 1、註意數據隔離性的問題，事務執行失敗，需要關註該次事務執行的沒有回滾的數據被別的事務利用，會產生臟讀的問題；業務上需要控制每個事務的隔離級別。二、實戰架構篇
這裡主要給大家介紹柔性分散式事務的實戰。鑒於剛性事務一般會被底層存執直接實現以及由於占有資源相時間較長吞吐量交差，這裡就不做介紹了。柔性事務分為兩種，同步事務和非同步事務。2.1 非同步事務
通過消息組件驅動的事務成為非同步事務。非同步事務的關註點在於必須保證發送MQ消息和本地事務執行是一個原子操作。這時候需要用戶事務消息。2.1.1 基於事務消息的非同步事務
具體過程如下： 1、發送半消息到MQ中去，這時候訂閱方式訂閱不到消息的；
2、執行後面的事務；
3、後面的事務執行成功，則commit這條消息，否則rollback這條消息；
概念介紹：半消息：對消息進行狀態標記，第一次發送將消息標記為“暫不投遞”狀態，訂閱方看不到該消息，此時的消息成為半點消息。消費端想要收到這條消息需要二次確認。 消息會查：由於網路閃斷，服務重啟等原因，導致半消息沒有進行二次確認，或者二次企確認消息丟失，這是MQ發現某條消息長時間處於“暫不投遞”狀態，需要主動向消息生產者查詢該消息的最終狀態（是commit，還是rollback），這個需要生產者自己來實現call back。 弊端： 1、業務侵入性比較高，需要實現事務性消息的callback，業務實現複雜； 2、不支持冪等，可能會產生多天這樣的消息。需要消費端做冪登處理； 3、發送消息失敗可能會導致業務執行失敗。
2.1.2 本地消息表架構
本質上就是將原來的事務消息改成本地消息表，在一個本地事務中完成消息落地和本地業務事務，然後通過微服務掃描未發送的消息，投遞到MQ Server中去。
缺點：需要增加一張與業務無法的表。
優點：
1、將消息服務和業務解耦解除MQ對業務的影響；
2、不用開發消息回查，減少主業務的侵入。
2.2 同步事務
一個分散式事務，所依賴的本地事務都需要直接調用完成，就稱之為同步事務。2.2.1 基於TCC事務架構
TCC 分散式事務模型包括三部分：
- 主業務服務：主業務服務為整個業務活動的發起方，服務的編排者，負責發起並完成整個業務活動。
- 從業務服務：從業務服務是整個業務活動的參與方，負責提供 TCC 業務操作，實現初步操作（Try）、確認操作（Confirm）、取消操作（Cancel）三個介面，供主業務服務調用。
- 業務活動管理器：以jar包組件的形式抽離出來，控制整個業務活動，包括記錄維護 TCC 全局事務的事務狀態和每個從業務服務的子事務狀態，併在業務活動提交時調用所有從業務服務的 Confirm 操作，在業務活動取消時調用所有從業務服務的 Cancel 操作。
2.2.2 Sage架構實戰
利用Fast Fail的思想在事務執行失敗的情況下直接快速返回，然後非同步執行補償，下麵是整體方案執行架構。將補償服務的調用和事務的控制過程通過AOP+微服務+註冊中心的形式抽離出來，讓後業務僅僅關註業務即可。
包含三個部分
- 微服務，是業務服務，主要處理實際業務，也是分散式事務的發起者，使用分散式事務只需要加入註解即可；
- 分散式事務Proxy組件，對事務進行追蹤管理以及收集每個本地事務的入參，回滾方法，以及事務執行結果，然後將這些數據落地，共補償事務服務調用使用；
- 分散式事務補償服務，掃描TDB(事務數據落地的DB)，執行事務失敗且沒有補償成功的事務，進行補償。
