分布式事務系列 - 解決跨庫轉賬問題

本文內容

1. 什么是分布式事務
2. 分布式事務中的難點
3. 常見的解決方案
4. 講解通過可靠消息來解決分布式事務

什么是分布式事務？

有這樣一個需求：

小明有兩個賬戶，分別位于A、B兩個數據庫中，小明需要將A中的資金轉到B中。

我們如何實現？

按照下面的方式實現看看有沒有問題。

1. 連接數據庫A，獲取connA連接
2. connA打開事務
3. A庫資金減少100
4. 連接庫B，獲取connB連接
5. connB打開事務
6. B庫資金增加100
7. connA.commit()
8. connB.commit()

上面操作，正常情況是沒有問題。

考慮如下情況：

第7步執行成功之后，網絡出問題了，第8步會提交失敗，此時的結果是：A庫資金減少了100，B庫資金卻沒有增加；這是一個網絡問題導致了我們業務失敗了，網絡因素是程序不可控的一些因素，還有其他的比如運行到7之后，系統突然斷電了，也會出現同樣的結果。造成了數據錯誤，對業務影響也是比較大的。

分布式事務可以這么理解：一個業務操作中，會包含很多子業務的，每個子業務都是獨立的事務，我們需要考慮的是如何保證這些子業務都成功，或者都失敗。

分布式事務中的難點

1. 分布式事務中，分支可能是各種各樣的，可能存在各種異常情況導致有些成功有些卻失敗了，這些情況需要我們程序能夠處理，保證所有的分支要么都成功、要么都失敗，不能出現部分成功而部分失敗的情況。
2. 分布式事務中，很難保證多個分支同時成功。每個分支可能都是提供遠程接口進行調用，之間存在網絡故障的問題，前面的分支調用成功了，但是其他分支由于網絡等不可控的因素而調用不成功，此時數據是很難做到同時一致性的。
3. 實時一致性難以保證。那么我們可以做到最終一致性也是可以的。

什么是最終一致性？

就拿上面的轉賬來說，A庫的資金減少了，由于網絡問題，操作B庫的connB連接斷開了，導致B庫資金沒有增加；網絡問題是可以恢復了，如果網絡恢復了，系統能夠給B中資金加上，這樣最終數據也是正確的；這中間有段時間AB庫的資金是不一致的（A庫減少了100，B庫應該增加100卻沒有增加，數據是不一致的），但是最終某個時間點數據變為一致了。能夠將不一致的時間降到最低是系統需要考慮的問題。

分布式事務中，我們可以接受數據在某個時間段之內不一致，但是數據最終在某個時間點是一致的。

常見解決方案

1. 可靠消息模式
2. TCC模式實現

分布式事務系列中主要講這2種方案，這兩種方案基本上可以解決大多數常見的分布式事務的問題，所以咱們必須把這兩種方式拿下。

下面我們介紹一下使用可靠消息如何實現？

可靠消息模式實現轉賬操作

兩個微服務
服務A：用于操作A庫中的賬戶
服務B：用于操作B庫中的賬戶

兩個服務都是鏈接獨立的數據庫，依靠數據庫提供的功能，能夠保證各自的事務。

對于用戶來說過程如下：

1. 調用服務A，扣款100
2. 發送扣款成功的消息到消息服務
3. 返回用戶轉賬已受理

接著

1. 服務B，拉取到轉賬消息
2. B庫中給賬戶+100
3. 調用消息服務將消息刪除
4. 服務B消費的過程中，比如出現網絡、機器重啟等原因，導致消費失敗，等機器恢復之后，可以再次消費這條消息，重試多次最終會成功

上面整個轉賬過程中有幾點我們需要考慮一下：

1. 如何確保A服務中扣款成功之后，消息一定能夠發送成功；如果消息發送失敗而丟失了，后面的業務將沒法進行。這塊涉及如何發送可靠消息，之前消息系列的文章有介紹，大家可以看一下：聊聊業務系統中投遞消息到mq的幾種方式
2. 我們的服務一般都是集群的方式，消息消費的時候，可能會出現一條消息并發消費的情況，并發情況發生的時候，如何確保消費只能夠被消費成功一次。如果一條轉賬消息被成功消費兩次，最終B賬戶中將增加200，導致業務出錯。這塊可以參考如何保證消息消費的冪等性，這塊之前也有講過，大家也可以看一下：探討一下實現冪等性的幾種方式

依靠消息模式實現分布式事物，比較適合消費者一定會處理成功的場景。比如用戶注冊發送郵件、發送短信、送積分等。

總結

1. 本文主要介紹了什么是分布式事務、其中的一些難點
2. 常見的使用最多的解決方案：異步消息處理分布式事物、tcc模式
3. tcc模式我們在后面的文章中介紹，目前在我們自己的系統中實現了通用的tcc，已經上線運行，運行也比較穩定
4. 對分布式事務有興趣、或有疑問的，可以加我微信itsoku交流
5. 請關注公眾號javacode2018，更多好文及時推送給您