一、什么是分布式事務
在早期的單體架構時期，所有的資料操作都在同一個資料庫里面進行，比如：A給B轉100塊錢，A的賬戶余額-100，B的賬戶余額+100，這兩個操作放在同一個事務里面即可，由資料庫來保證事務的原子性、一致性、持久性、隔離性，但是隨著業務量、資料量的加大，放在一個資料庫里面很難支撐，所以需要對資料庫按照業務來進行拆分，比如積分兌換商品下單操作涉及如下操作：
1.用戶積分扣減（積分資料庫）
2.商品庫存扣減（商品庫存資料庫）
3.訂單創建（訂單資料庫）
這三個操作在三個不同的資料庫里面進行，這樣就導致傳統的資料庫事務不能保證這三個操作的原子性了，于是就需要分布式事務來處理這類問題，
二、常見的分布式事務解決方案有哪些？
1.兩階段提交協議
由事務協調者和事務參與者構成，把分布式事務分成兩個階段：
一階段：事務協調者呼叫各個事務參與者進行資源準備，這個階段各個參與者會執行本地事務，進入prepare階段，但是本地事務不會提交；
二階段：事務協調者根據呼叫結果，來決定第二階段是執行commit還是rollback操作，如果一階段中只要有一個參與者回傳失敗，就執行rollback操作，只有當所有參與者都回傳成功時才執行commit操作，
兩階段協議有什么缺點呢？
（1）性能較差：因為會阻塞性的鎖定資料庫資源，如果其中某個參與者執行很慢，其它的參與者也需要等著；
（2）可能導致資料不一致：如果參與者和協調者都掛了；
（3）可靠性較差：協調者存在單點故障的問題，如果出現故障，參與者就會一直處于阻塞狀態，
2.三階段提交協議
在兩階段提交的基礎上多加了一個階段：先問一下每個參與者是否可以提交事務，如果可以就會進入第二階段，這個階段會鎖定資料庫資源，后面兩個階段在兩階段協議的基礎上增加了參與者如果等待協調者超時，可以直接提交事務的處理，
三階段的優點：如果協調者出現問題，參與者不會一直阻塞；
缺點：沒有解決資料一致性的問題，在第三階段如果協調者出現問題時可能導致資料不一致，
3.TCC
一階段為try,二階段為confirm或者cancel；2PC和3PC都是資料庫層面的，而 TCC 是業務層面的分布式事務，就像我前面說的分布式事務不僅僅包括資料庫的操作，還包括發送短信等，這時候 TCC 就派上用場了！
TCC屬于補償型事務，一階段會先預留資源，如果成功則確認，否則補償退回就行，
TCC最大的缺點就是需要自己實作try、confirm、cancel三個方法，對業務侵入性較大，實作起來也會比較麻煩，使用TCC要注意一下幾個問題：
（1）慷訓滾：如果try還沒執行，cancel方法就執行了，這個時候沒有資源可以補償，需要允許這種case發生，直接發揮成功就好；
（2）防懸掛：上面說到了允許慷訓滾的發生，那try方法可能后面又會執行，如果不處理，會導致資源會鎖住了，并且不會釋放；
（3）冪等：confirm、cancel方法需要考慮網路等問題導致的執行失敗，需要重試的問題，
4.本地事務表
缺點：需要增加本地訊息表，對業務侵入較大，
5.事務性訊息
不是所有的訊息中間件都支持，目前主流的只有rocketMq支持，同時對業務也有一定的侵入，與TCC相比，二者使用的場景不太一樣，TCC一階段就會鎖定所有資源，如果失敗了解除資源鎖定就好了，但是事務性訊息并沒有鎖定所有資源，生產者發送成功了，通過重試的方式保證消費者也能消費成功，如果消費不成功需要告警然后人工介入處理，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/541417.html
標籤：其他
下一篇：客服系統即時通訊IM開發（二）Golang + Gin框架實作服務端WebScoket【唯一客服】網站在線客服系統