分布式事務介紹與優化

一、分布式事務介紹

分布式事務用于在分布式系統中保證不同節點之間的數據一致性。分布式事務的實現有很多種，最具有代表性的是由Oracle Tuxedo系統提出的XA分布式事務協議。

在我們平時寫的代碼中，我們可以用一個事務包含許多個SQL調用，如果某一個數據庫操作發生異常，就可以將之前的SQL操縱全部進行回滾，只有當所以的SQL操作全部成功，才進行提交，這就保證了事務的一致性。

但是在分布式環境下，多個數據庫操作可能被拆分到獨立的三個數據庫訪問服務中，此時原來的本地SQL調用就演變成了遠程服務調用，事務的一致性無法得到保證

加入服務A和服務B調用成功，則A和B的SQL會被提交，最后執行服務C，它的SQL操作失敗，那么C進行回滾，在這里，就導致了事務的不一致。

二、分布式事務設計方案

通常，分布式事務基于兩階段實現：

 階段1：全局事務管理器向所有事務參與者發送準備請求，事務參與者向全局事務管理器回復自己是否準備就緒。

階段2：全局事務管理器接收到所以事務參與者的回復之后做判斷，如果所有事務參與者都可以提交，則向所有事務提交者發送提交申請，否則進行回滾。事務參與者根據全局事務管理器的指令進行提交或者回滾操作。

兩個階段采用的是悲觀鎖策略，由于各個事務參與者需要等待響應最慢的參與者，因此性能比較差。 而且整個過程都是需要加鎖的，并且當協調者出現故障，則整個事務需要等到協調者回復后才能繼續執行。

所以可以用最終一致性替代傳統的強一致性，盡量避免使用分布式事務。

三、分布式事務基礎模型

由于在大型SOA/微服務系統架構下，一次業務請求往往會跨越多個服務，多個服務共同協調完成一次端到端的全鏈路業務調用時，由于業務約束或者服務提供者的故障等原因造成多個系統中數據不一致或通信延遲等問題，因此對于分布式/微服務系統中的多服務協調調用場景需要分布式事務來保證系統的ACID屬性。

四、分布式事務優化

在實踐中常用的最終一致性方案就是使用帶有事務功能的MQ做中間人角色，工作原理如下：

在做本地事務之前，先向MQ發送一個preapre消息，然后執行本地事務，本地事務提交成功的話，向MQ發送一個commit消息，否則發送一個rollback消息，取消之前的消息。MQ只會在收到commit確認才會將消息投遞出去，所以這樣的形式可以保證在一切正常的情況下，本地事務和MQ可以達到一致性。

但是如果系統執行事務成功后，還沒來得及發送commit給MQ，或者說網絡超時等問題導致MQ沒有收到commit，那么MQ就不會把prepare消息投遞出去。MQ會根據策略去嘗試詢問（回調）發消息的系統進行檢查該消息是否應該投遞出去或者丟棄，得到系統的確認后，MQ會做投遞還是丟棄，這樣就完全保證了MQ和發消息的系統的一致性，從而保證了接收消息系統的一致性。