分布式事務(wù)介紹與優(yōu)化

一、分布式事務(wù)介紹

分布式事務(wù)用于在分布式系統(tǒng)中保證不同節(jié)點(diǎn)之間的數(shù)據(jù)一致性。分布式事務(wù)的實現(xiàn)有很多種，最具有代表性的是由Oracle Tuxedo系統(tǒng)提出的XA分布式事務(wù)協(xié)議。

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

但是在分布式環(huán)境下，多個數(shù)據(jù)庫操作可能被拆分到獨(dú)立的三個數(shù)據(jù)庫訪問服務(wù)中，此時原來的本地SQL調(diào)用就演變成了遠(yuǎn)程服務(wù)調(diào)用，事務(wù)的一致性無法得到保證

加入服務(wù)A和服務(wù)B調(diào)用成功，則A和B的SQL會被提交，最后執(zhí)行服務(wù)C，它的SQL操作失敗，那么C進(jìn)行回滾，在這里，就導(dǎo)致了事務(wù)的不一致。

二、分布式事務(wù)設(shè)計方案

通常，分布式事務(wù)基于兩階段實現(xiàn)：

 階段1：全局事務(wù)管理器向所有事務(wù)參與者發(fā)送準(zhǔn)備請求，事務(wù)參與者向全局事務(wù)管理器回復(fù)自己是否準(zhǔn)備就緒。

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

兩個階段采用的是悲觀鎖策略，由于各個事務(wù)參與者需要等待響應(yīng)最慢的參與者，因此性能比較差。 而且整個過程都是需要加鎖的，并且當(dāng)協(xié)調(diào)者出現(xiàn)故障，則整個事務(wù)需要等到協(xié)調(diào)者回復(fù)后才能繼續(xù)執(zhí)行。

所以可以用最終一致性替代傳統(tǒng)的強(qiáng)一致性，盡量避免使用分布式事務(wù)。

三、分布式事務(wù)基礎(chǔ)模型

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

四、分布式事務(wù)優(yōu)化

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

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

但是如果系統(tǒng)執(zhí)行事務(wù)成功后，還沒來得及發(fā)送commit給MQ，或者說網(wǎng)絡(luò)超時等問題導(dǎo)致MQ沒有收到commit，那么MQ就不會把prepare消息投遞出去。MQ會根據(jù)策略去嘗試詢問（回調(diào)）發(fā)消息的系統(tǒng)進(jìn)行檢查該消息是否應(yīng)該投遞出去或者丟棄，得到系統(tǒng)的確認(rèn)后，MQ會做投遞還是丟棄，這樣就完全保證了MQ和發(fā)消息的系統(tǒng)的一致性，從而保證了接收消息系統(tǒng)的一致性。