分布式一致性
分布式場景下，多個服務同時對服務乙個流程，比如電商下單場景，需要支付服務進行支付、庫存服務扣減庫存、訂單服務進行訂單生成、物流服務更新物流資訊等。如果某乙個服務執行失敗，或者網路不通引起的請求丟失，那麼整個系統可能出現資料不一致的原因。
上述場景就是分布式一致性問題，追根到底，分布式一致性的根本原因在於資料的分布式操作，引起的本地事務無法保障資料的原子性引起。
分布式一致性問題的解決思路有兩種，一種是分布式事務，一種是盡量通過業務流程避免分布式事務。分布式事務是直接解決問題，而業務規避其實通過解決出問題的地方(解決提問題的人)。其實在真實業務場景中，如果業務規避不是很麻煩的前提，最優雅的解決方案就是業務規避。
事務分類
分布式事務實現方案從型別上去分剛性事務、柔型事務。剛性事務：通常無業務改造，強一致性，原生支援回滾/隔離性，低併發，適合短事務。柔性事務：有業務改造，最終一致性，實現補償介面，實現資源鎖定介面，高併發，適合長事務。
剛性事務：xa 協議（2pc、jta、jts）、3pc
柔型事務：tcc/fmt、saga（狀態機模式、aop模式）、本地事務訊息、訊息事務（半訊息）
2pc定義
2pc全稱two-phasecommit，中文名是二階段提交，是xa規範的實現思路，xa規範是 x/open dtp 定義的交易中介軟體與資料庫之間的介面規範（即介面函式），交易中介軟體用它來通知資料庫事務的開始、結束以及提交、回滾等。xa 介面函式由資料庫廠商提供。
x/open dtp是x/open 組織（即現在的 open group ）1994定義的分布式事務處理模型。xa規模型包括應用程式（ ap ）、事務管理器（ tm ）、資源管理器（ rm ）、通訊資源管理器（ crm ）四部分。一般，常見的事務管理器（ tm ）是交易中介軟體，常見的資源管理器（ rm ）是資料庫，常見的通訊資源管理器（ crm ）是訊息中介軟體。
2pc 通常使用到xa中的三個角色tm、ap
ap：事務發起方，通常為微服務自身；定義事務邊界(事務開始、結束)，並訪問事務邊界內的資源
tm：事務協調方，事務操作總控；管理事務全域性事務，分配事務唯一標識，監控事務的執行進度，負責事務的提交、回滾、失敗恢復。
rm：本地事務資源，根據協調方命令進行操作；管理本地共享資源(既資料庫)。
2pc流程
2pc 分成2個階段，第一階段：請求階段（commit-request phase，或稱表決階段，voting phase）和第二階段：提交階段（commit phase）。
表決階段：事務協調者™序列給每個參與者(rm)傳送prepare訊息，每個參與者要麼直接返回失敗，要麼在本地sql執行、記錄事務日誌(undo、redo)，但不提交，到達一種「萬事俱備，只欠東風」的狀態。
可以進一步將準備階段分為以下三個步驟：
1）tm序列向每個參與者節點詢問是否可以執行提交操作，並等待各參與者節點的響應。
2）參與者節點執行詢問的所有sql語句，並將undo和redo寫入日誌。
3）各參與者節點響應tm發起的詢問。如果參與者節點的事務操作實際執行成功，則返回乙個」success」訊息；如果參與者節點的事務操作實際執行失敗，則返回乙個」abort」訊息。
提交階段：如果tm收到了參與者的失敗訊息或者超時，直接給每個參與者傳送回滾(rollback)訊息；否則，傳送提交(commit)訊息；參與者根據tm的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源。(注意:必須在最後階段釋放鎖資源)
分支一–當tm從所有參與者節點獲得的相應訊息都為」success」時：
1）tm向所有參與者節點發出」正式提交(commit)」的請求。
2）參與者節點正式完成操作，並釋放在整個事務期間內占用的資源。
3）參與者節點向tm傳送」完成」訊息。
4）tm受到所有參與者節點反饋的」完成」訊息後，完成事務。
分支二–如果任一參與者節點在第一階段返回的響應訊息為」abort」，或者 tm在第一階段的詢問超時之前無法獲取所有參與者節點的響應訊息時：
1）tm向所有參與者節點發出」回滾操作(rollback)」的請求。
2）參與者節點利用之前寫入的undo資訊執行回滾，並釋放在整個事務期間內占用的資源。
3）參與者節點向tm傳送」回滾完成」訊息。
4）tm受到所有參與者節點反饋的」回滾完成」訊息後，取消事務。
不管最後結果如何，第二階段都會結束當前事務。
總結2pc雖然將xa規範方案細化成思路，也形成了流程圖，大部情況下確實能提供原子性操作，但是仍存在一定問題，所以又出現了3pc。
分布式場景之剛性事務 2PC詳解
分布式一致性 分布式場景下，多個服務同時對服務乙個流程，比如電商下單場景，需要支付服務進行支付 庫存服務扣減庫存 訂單服務進行訂單生成 物流服務更新物流資訊等。如果某乙個服務執行失敗，或者網路不通引起的請求丟失，那麼整個系統可能出現資料不一致的原因。上述場景就是分布式一致性問題，追根到底，分布式一致...
分布式場景之剛性事務 2PC詳解
分布式一致性 分布式場景下，多個服務同時對服務乙個流程，比如電商下單場景，需要支付服務進行支付 庫存服務扣減庫存 訂單服務進行訂單生成 物流服務更新物流資訊等。如果某乙個服務執行失敗，或者網路不通引起的請求丟失，那麼整個系統可能出現資料不一致的原因。上述場景就是分布式一致性問題，追根到底，分布式一致...
分布式事務設計之同步場景
1.同步場景 2 寫場景 購買商品 下單 a 減庫存 b 支付 c 2.解決方案 1 基於非同步補償的分布式事務 2 架構設計的三大關鍵點 如以寫場景為例 針對每個步驟的請求都需要在事務補償服務的資料庫中存放事務id state,ts 每個微服務資料訪問層提供補償介面，如下圖 3.業務邏輯層prox...