漫画：什么是分布式事务
轉載自?漫畫：什么是分布式事務？
—————? 第二天? —————
————————————
假如沒有分布式事務
在一系列微服務系統當中，假如不存在分布式事務，會發生什么呢？讓我們以互聯網中常用的交易業務為例子：
上圖中包含了庫存和訂單兩個獨立的微服務，每個微服務維護了自己的數據庫。在交易系統的業務邏輯中，一個商品在下單之前需要先調用庫存服務，進行扣除庫存，再調用訂單服務，創建訂單記錄。
正常情況下，兩個數據庫各自更新成功，兩邊數據維持著一致性。
但是，在非正常情況下，有可能庫存的扣減完成了，隨后的訂單記錄卻因為某些原因插入失敗。這個時候，兩邊數據就失去了應有的一致性。
什么是分布式事務？
分布式事務用于在分布式系統中保證不同節點之間的數據一致性。分布式事務的實現有很多種，最具有代表性的是由Oracle Tuxedo系統提出的XA分布式事務協議。
XA協議包含兩階段提交（2PC）和三階段提交（3PC）兩種實現，這里我們重點介紹兩階段提交的具體過程。
在魔獸世界這款游戲中，副本組團打BOSS的時候，為了更方便隊長與隊員們之間的協作，隊長可以發起一個“就位確認”的操作：
當隊員收到就位確認提示后，如果已經就位，就選擇“是”，如果還沒就位，就選擇“否”。
當隊長收到了所有人的就位確認，就會向所有隊員們發布消息，告訴他們開始打BOSS。
相應的，在隊長發起就位確認的時候，有可能某些隊員還并沒有就位：
以上就是魔獸世界當中組團打BOSS的確認流程。這個流程和XA分布式事務協議的兩階段提交非常相似。
那么XA協議究竟是什么樣子呢？在XA協議中包含著兩個角色：事務協調者和事務參與者。讓我們來看一看他們之間的交互流程：
第一階段：
在XA分布式事務的第一階段，作為事務協調者的節點會首先向所有的參與者節點發送Prepare請求。
在接到Prepare請求之后，每一個參與者節點會各自執行與事務有關的數據更新，寫入Undo Log和Redo Log。如果參與者執行成功，暫時不提交事務，而是向事務協調節點返回“完成”消息。
當事務協調者接到了所有參與者的返回消息，整個分布式事務將會進入第二階段。
第二階段：
在XA分布式事務的第二階段，如果事務協調節點在之前所收到都是正向返回，那么它將會向所有事務參與者發出Commit請求。
接到Commit請求之后，事務參與者節點會各自進行本地的事務提交，并釋放鎖資源。當本地事務完成提交后，將會向事務協調者返回“完成”消息。
當事務協調者接收到所有事務參與者的“完成”反饋，整個分布式事務完成。
以上所描述的是XA兩階段提交的正向流程，接下來我們看一看失敗情況的處理流程：
第一階段：
第二階段：
在XA的第一階段，如果某個事務參與者反饋失敗消息，說明該節點的本地事務執行不成功，必須回滾。
于是在第二階段，事務協調節點向所有的事務參與者發送Abort請求。接收到Abort請求之后，各個事務參與者節點需要在本地進行事務的回滾操作，回滾操作依照Undo Log來進行。
以上就是XA兩階段提交協議的詳細過程。
XA兩階段提交的不足
XA兩階段提交究竟有哪些不足呢？
1.性能問題
XA協議遵循強一致性。在事務執行過程中，各個節點占用著數據庫資源，只有當所有節點準備完畢，事務協調者才會通知提交，參與者提交后釋放資源。這樣的過程有著非常明顯的性能問題。
2.協調者單點故障問題
事務協調者是整個XA模型的核心，一旦事務協調者節點掛掉，參與者收不到提交或是回滾通知，參與者會一直處于中間狀態無法完成事務。
3.丟失消息導致的不一致問題。
在XA協議的第二個階段，如果發生局部網絡問題，一部分事務參與者收到了提交消息，另一部分事務參與者沒收到提交消息，那么就導致了節點之間數據的不一致。
如果避免XA兩階段提交的種種問題呢？有許多其他的分布式事務方案可供選擇：
1.XA三階段提交
XA三階段提交在兩階段提交的基礎上增加了CanCommit階段，并且引入了超時機制。一旦事物參與者遲遲沒有接到協調者的commit請求，會自動進行本地commit。這樣有效解決了協調者單點故障的問題。但是性能問題和不一致的問題仍然沒有根本解決。
2.MQ事務
利用消息中間件來異步完成事務的后一半更新，實現系統的最終一致性。這個方式避免了像XA協議那樣的性能問題。
3.TCC事務
TCC事務是Try、Commit、Cancel三種指令的縮寫，其邏輯模式類似于XA兩階段提交，但是實現方式是在代碼層面來人為實現。
幾點補充：
.本漫畫純屬娛樂，還請大家盡量珍惜當下的工作，切勿模仿小灰的行為哦。
—————END—————
總結
以上是生活随笔為你收集整理的漫画：什么是分布式事务的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 为什么电脑提示此网络中另一台计算机与此计
- 下一篇： TCP接入层的负载均衡、高可用、扩展性架