什麼是分布式事務
分布式事務中的難點
常見的解決方案
講解通過可靠訊息來解決分布式事務
有這樣乙個需求：
小明有兩個賬戶，分別位於a、b兩個資料庫中，小明需要將a中的資金轉到b中。
我們如何實現？
按照下面的方式實現看看有沒有問題。
連線資料庫a，獲取conna連線
conna開啟事務
a庫資金減少100
連線庫b，獲取connb連線
connb開啟事務
b庫資金增加100
conna.commit()
connb.commit()
上面操作，正常情況是沒有問題。
考慮如下情況：
第7步執行成功之後，網路出問題了，第8步會提交失敗，此時的結果是：a庫資金減少了100，b庫資金卻沒有增加；這是乙個網路問題導致了我們業務失敗了，網路因素是程式不可控的一些因素，還有其他的比如執行到7之後，系統突然斷電了，也會出現同樣的結果。造成了資料錯誤，對業務影響也是比較大的。
分布式事務可以這麼理解：乙個業務操作中，會包含很多子業務的，每個子業務都是獨立的事務，我們需要考慮的是如何保證這些子業務都成功，或者都失敗。
分布式事務中，分支可能是各種各樣的，可能存在各種異常情況導致有些成功有些卻失敗了，這些情況需要我們程式能夠處理，保證所有的分支要麼都成功、要麼都失敗，不能出現部分成功而部分失敗的情況。
分布式事務中，很難保證多個分支同時成功。每個分支可能都是提供遠端介面進行呼叫，之間存在網路故障的問題，前面的分支呼叫成功了，但是其他分支由於網路等不可控的因素而呼叫不成功，此時資料是很難做到同時一致性的。
實時一致性難以保證。那麼我們可以做到最終一致性也是可以的。
就拿上面的轉賬來說，a庫的資金減少了，由於網路問題，操作b庫的connb連線斷開了，導致b庫資金沒有增加；網路問題是可以恢復了，如果網路恢復了，系統能夠給b中資金加上，這樣最終資料也是正確的；這中間有段時間ab庫的資金是不一致的（a庫減少了100，b庫應該增加100卻沒有增加，資料是不一致的），但是最終某個時間點資料變為一致了。能夠將不一致的時間降到最低是系統需要考慮的問題。
分布式事務中，我們可以接受資料在某個時間段之內不一致，但是資料最終在某個時間點是一致的。
可靠訊息模式
tcc模式實現
分布式事務系列中主要講這2種方案，這兩種方案基本上可以解決大多數常見的分布式事務的問題，所以咱們必須把這兩種方式拿下。
下面我們介紹一下使用可靠訊息如何實現？
兩個微服務
服務a：用於操作a庫中的賬戶
服務b：用於操作b庫中的賬戶
兩個服務都是鏈結獨立的資料庫，依靠資料庫提供的功能，能夠保證各自的事務。
對於使用者來說過程如下：
呼叫服務a，扣款100
傳送扣款成功的訊息到訊息服務
返回使用者轉賬已受理
接著服務b，拉取到轉賬訊息
b庫中給賬戶+100
呼叫訊息服務將訊息刪除
服務b消費的過程中，比如出現網路、機器重啟等原因，導致消費失敗，等機器恢復之後，可以再次消費這條訊息，重試多次最終會成功
上面整個轉賬過程中有幾點我們需要考慮一下：
如何確保a服務中扣款成功之後，訊息一定能夠傳送成功；如果訊息傳送失敗而丟失了，後面的業務將沒法進行。這塊涉及如何傳送可靠訊息，之前訊息系列的文章有介紹，大家可以看一下：聊聊業務系統中投遞訊息到mq的幾種方式
我們的服務一般都是集群的方式，訊息消費的時候，可能會出現一條訊息併發消費的情況，併發情況發生的時候，如何確保消費只能夠被消費成功一次。如果一條轉賬訊息被成功消費兩次，最終b賬戶中將增加200，導致業務出錯。這塊可以參考如何保證訊息消費的冪等性，這塊之前也有講過，大家也可以看一下：**一下實現冪等性的幾種方式
依靠訊息模式實現分布式事物，比較適合消費者一定會處理成功的場景。比如使用者註冊傳送郵件、傳送簡訊、送積分等。
本文主要介紹了什麼是分布式事務、其中的一些難點
常見的使用最多的解決方案：非同步訊息處理分布式事物、tcc模式
tcc模式我們在後面的文章中介紹，目前在我們自己的系統中實現了通用的tcc，已經上線執行，執行也比較穩定
解決分布式事務
1.分布式解決方案 2.非常詳細的乙個業務邏輯 至於消費端消費失敗？通過 返回訊息的狀態，過一段時間，rocketmq會繼續傳送 漲姿勢了 2段式 先查詢每個資料庫的狀態，ok了之後，第2段是本地執行然後提交事務。事務管理器 atomikos,jtom,bitromix 缺點是 一旦詢問的階段機器掛...
解決分布式事務的問題
理論說明 1 資料庫的2階段提交協議 2pc或者稱為xa transactions 第一階段 事務協調器要求涉及事務的資料庫都預提交，並反饋是否可以提交 第二階段 事務協調器要求每個資料庫提交 回滾資料 2 base理論 對cap進一步補充 3 xa xa 是指由 x open 組織提出的分布式事務...
WCF系列 分布式事務
跟wcf 相關的事務協議有三個。這是個輕量級的本地事務協議，限制管理在乙個 中的事務。不能跨 邊界傳播事務，也不能跨服務邊界傳播事務。跟其他協議比，lightweight protocol 是最有效率的協議。這個協議可用於跨 程序和機器邊界，管理兩階段提交的事務協議。這個跨邊界的事務協議使用 rpc...