web分布式事務(wù)舉例分析

本篇內(nèi)容介紹了“web分布式事務(wù)舉例分析”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

在分布式時代，分庫分表是很常見的，微服務(wù)系統(tǒng)中，各個系統(tǒng)通常使用獨立的數(shù)據(jù)庫，所以，事務(wù)很難靠數(shù)據(jù)庫本身保證，只能靠業(yè)務(wù)系統(tǒng)來解決。

例如支付寶中的余額寶、花唄，具體不清楚，但猜測應(yīng)該就是2個服務(wù)，不是同一個數(shù)據(jù)庫，我們還花唄的時候通常都是從余額寶中扣除的，這就是分布式事務(wù)，一個系統(tǒng)中扣減錢，一個系統(tǒng)中增加錢。

下面我們分析下最終一致性的實現(xiàn)方案，最終一致性通常都是使用消息中間件來實現(xiàn)的，系統(tǒng)結(jié)構(gòu)如下：

用戶向系統(tǒng)A發(fā)起轉(zhuǎn)賬請求，A先在自己的數(shù)據(jù)庫中扣錢，然后通過消息中間件告訴B應(yīng)該加錢，B收到后在自己的數(shù)據(jù)庫中加錢。

這里有個關(guān)鍵問題，A更新數(shù)據(jù)庫和給消息中間件發(fā)消息是2個操作，如下兩個場景怎么處理：

先更新數(shù)據(jù)庫，成功了，但發(fā)送消息失敗了，重發(fā)多次還是失敗

先發(fā)消息，成功了，但數(shù)據(jù)庫更新失敗，消息撤不回來了

都是因為這2個操作不是原子的，發(fā)做誰都有問題。

那看下這樣做是否可以，就是把更新數(shù)據(jù)庫和給消息中間件發(fā)消息放到一個事務(wù)中，這樣不就原子了嗎？

有問題，例如：

如果消息發(fā)送失敗，具體問題出在哪兒？是消息中間件根本就沒收到消息，還是收到消息后response時出錯了？如果是根本沒收到還好一點，如果是收到了但響應(yīng)失敗就麻煩了，導(dǎo)致A數(shù)據(jù)庫回滾，沒有扣錢，但B收到消息了，加錢了。

如果發(fā)消息時網(wǎng)絡(luò)延遲很高怎么辦，數(shù)據(jù)庫事務(wù)一直被拖著，性能差，風(fēng)險高。

所以，放入一個事務(wù)中這種方法是不可取的。

為了保證原子性，可以變通一下，添加一個消息表，A不直接往消息中間件中發(fā)消息，而是把消息寫入消息表，然后通過一個后臺程序不斷的把消息寫入消息中間件。

這個后臺程序源源不斷的把消息表中的消息發(fā)到消息中間件，如果失敗就重試，可以保證：

消息不會丟失

順序不亂

但會有消息重復(fù)的情況，因為消息發(fā)送失敗可能是寫入失敗，也可能是寫入成功但響應(yīng)失敗，所以消息可能會重復(fù)，這個問題需要系統(tǒng)B來處理。

系統(tǒng)B需要考慮2個問題：

消息丟失

B從消息中間件中拿到消息，還沒處理完就宕機了，這條消息怎么辦？

需要通過ACK機制處理，消費成功的發(fā)送ACK，對于沒有ACK的消息，消息中間件會再次推送。

消息重復(fù)

ACK機制也存在消息重復(fù)的情況，比如B已經(jīng)處理完一條消息，發(fā)ACK時失敗了，那么這條消息就還會被推過來。

還有就是上面說的后臺程序發(fā)消息時可能重復(fù)。

對于重復(fù)消息問題，可以加一個判重表，記錄處理成功的消息，每次收到消息時，先通過判重表判斷一下，如果重復(fù)了就不處理，實現(xiàn)冪等性。

這樣，整體結(jié)構(gòu)就變?yōu)椋?/p>

“web分布式事務(wù)舉例分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！