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