java、後端開發、程序員、分佈式事務
分佈式事務應該是面試官最喜歡問的題目之一
我對分佈式事務的基本思路整理總結了一下，其實還有很多細節沒研究。
基礎知識準備
數據庫事務、分佈式、微服務、分庫分表數據庫事務的特性：原子性(Atomicity )、一致性( Consistency )、隔離性或獨立性( Isolation)和持久性(Durabilily)，簡稱就是ACID上面基礎都不清楚，建議先把這些知識熟悉後在研究分佈式事務。為什麼有分佈式事務
由於業務數據量非常巨大，如淘寶電商系統，後端肯定是分庫分表的。因為單個數據庫數據量壓上來，系統就會產生性能瓶頸。
庫存和訂單分別在不同數據庫中。
交易系統、庫存系統、訂單系統。【微服務架構中，像淘寶光一個下單鏈路可能會涉及10多個系統以上】
如果下訂單失敗庫存系統必須回滾數據，保證數據強一致性。
分佈式事務種類
數據庫的2PC（兩階段提交）又叫做 XA Transactions，強一致性、性能不高補償事務（TCC），記住3個單詞 try、confirm、cancel，2PC（兩階段提交）
2階段提交是分佈式事務傳統解決方案，目測銀行保險都喜歡用這個。
當事務跨越多個節點時，為了保持事務ACID，引入了協調者、參與者
第一階段：事務協調器要求每個涉及到事務的數據庫預提交(precommit)此操作，並反映是否可以提交.第二階段：事務協調器要求每個數據庫提交數據。把下面圖理解到位了，2PC模式的思路就理解了
協調者=事務協調器、參與者=本地資源管理器預備-提交
缺點：2PC效率很低，對高併發很不友好兩階段提交涉及多次節點的網絡通信，導致通信時間過長。非常容易造成長事務，鎖定資源時間太長，資源等待時間增多。大部分高併發場景都應該避免使用。
補償事務（TCC）
舉例
Try 減庫存Confirm 更新訂單如果更新訂單失敗，就進入Cancel階段 恢復庫存，回滾階段是業務編碼來實現的（一個sql把庫存更新回去）,不同業務場景需要不同的補償代碼，複用性差。缺點：對應用侵入性強、實現難度大優點：降低鎖衝突、提高吞吐量成為可能，靈活自定義數據庫操作的粒度消息事務
思路：將本地事務和消息中間件放在一個事務中。
保證最終一致性，過程不能保證
缺點：基於消息的最終一致性方案應用對應用侵入性高，需要大量業務改造成本高
分佈式事務異常情況
下面這些異常，都需要考慮
偽分佈式事務
例子：數據不一致情況
當遠程接口rpc執行成功，但超時返回異常，導致事務回滾而訂單表卻執行成功了。