1. 什麼是分布式事務？
分布式事務用於在分布式系統中保證不同節點之間的資料一致性。
舉例：有兩個系統--訂單系統和庫存系統，我們的業務邏輯在執行訂單和庫存的時候，需要保證要麼都成功，要麼都失敗。在單機系統中，我們可以直接通過事務來保證，而在分布式系統中，我們就需要分布式事務保證了。
2. 有哪些分布式的事務方案呢？
2.1 兩階段提交方案（xa方案）
2.2 tcc（補償事務）
2.3 本地訊息表（非同步確保）
2.4 可靠訊息最終一致性方案（mq）
2.5 最大努力方案
2.6 三階段提交方案
2.7 sagas 事務模型
3. 兩階段提交方案（xa方案）
xa 是乙個兩階段提交協議，該協議分為以下兩個階段：
兩階段提交這種解決方案屬於犧牲了一部分可用性來換取的一致性。
優點：原理簡單，實驗方便；盡量保證了資料的強一致，適合對資料強一致要求很高的關鍵領域。（其實也不能100%保證強一致）
缺點：實現複雜，犧牲了可用性，對效能影響較大，因為嚴重依賴於資料庫層面來搞定複雜的事務，效率很低，不適合高併發高效能場景
同步阻塞：在二階段提交的執行過程中，所有的參與該事務操作的邏輯都會處於阻塞狀態。
單點問題：協調者出現問題，事務無法完成 還會處於鎖定的狀態。
4. tcc（補償事務）
tcc 其實就是採用的補償機制，其核心思想是：針對每個操作，都要註冊乙個與其對應的確認和補償（撤銷）操作。它分為三個階段：
因為這個事務回滾實際上是嚴重依賴於你自己寫**來回滾和補償了，會造成補償**巨大，非常之噁心。一般用在跟錢相關的，跟錢打交道的，支付、交易相關的場景，嚴格保證分布式事務要麼全部成功，要麼全部自動回滾，嚴格保證資金的正確性。
5. 本地訊息表
1）a系統在自己本地乙個事務裡操作同時插入一條資料到訊息表；
2）接著a系統將這個訊息傳送到mq中去；
3）b系統接收到訊息之後，在乙個事務裡，往自己本地訊息表裡插入一條資料，同時執行其他的業務操作，如果這個訊息已經被處理過了，那麼此時這個事務會回滾，這樣保證不會重複處理訊息；
4）b系統執行成功之後，就會更新自己本地訊息表的狀態以及a系統訊息表的狀態；
5）如果b系統處理失敗了，那麼就不會更新訊息表狀態，那麼此時a系統會定時掃瞄自己的訊息表，如果有沒處理的訊息，會再次傳送到mq中去，讓b再次處理；
6）這個方案保證了最終一致性，哪怕b事務失敗了，但是a會不斷重發訊息，直到b那邊成功為止；
這種方案遵循base理論，採用的是最終一致性，比較適合實際業務場景的，即不會出現像2pc那樣複雜的實現(當呼叫鏈很長的時候，2pc的可用性是非常低的)，也不會像tcc那樣可能出現確認或者回滾不了的情況。
優點：一種非常經典的實現，避免了分布式事務，實現了最終一致性。
缺點：訊息表會耦合到業務系統中，如果沒有封裝好的解決方案，會有很多雜活需要處理。嚴重依賴於資料庫的訊息表來管理事務。不適合高併發的場景。
6.可靠訊息最終一致性方案（mq）
1）a系統先傳送乙個prepared訊息到mq，如果這個prepared訊息傳送失敗那麼就直接取消操作別執行了
2）如果這個訊息傳送成功過了，那麼接著執行本地事務，如果成功就告訴mq傳送確認訊息，如果失敗就告訴mq回滾訊息
3）如果傳送了確認訊息，那麼此時b系統會接收到確認訊息，然後執行本地的事務
4）mq會自動定時輪詢所有prepared訊息**你的介面，問你，這個訊息是不是本地事務處理失敗了，所有沒傳送確認訊息？那是繼續重試還是回滾？一般來說這裡你就可以查下資料庫看之前本地事務是否執行，如果回滾了，那麼這裡也回滾吧。這個就是避免可能本地事務執行成功了，別確認訊息傳送失敗了。
5）這個方案裡，要是系統b的事務失敗了咋辦？重試咯，自動不斷重試直到成功，如果實在是不行，要麼就是針對重要的資金類業務進行回滾，比如b系統本地回滾後，想辦法通知系統a也回滾；或者是傳送報警由人工來手工回滾和補償
優點：實現了最終一致性，不需要依賴本地資料庫事務。
缺點：實現難度大，主流mq不支援，rocketmq事務訊息部分**也未開源。
7 最大努力方案
1）系統a本地事務執行完之後，傳送個訊息到mq
2）這裡會有個專門消費mq的最大努力通知服務，這個服務會消費mq然後寫入資料庫中記錄下來，或者是放入個記憶體佇列也可以，接著呼叫系統b的介面
3）要是系統b執行成功就ok了；要是系統b執行失敗了，那麼最大努力通知服務就定時嘗試重新呼叫系統b，反覆n次，最後還是不行就放棄
8. 三階段提交方案
階段一：事務詢問（cancommit請求），詢問參與者；參與者想協調者反饋事務詢問的響應。
階段二：協調者根據參與者的反饋決定是否可以進行事務的precommit操作，1）執行事務預提交2）中斷事務
階段三：執行提交或者中斷事務；
在階段三中，存在的故障：協調者出現問題，協調者和參與者之間的網路出現故障；在這種異常中，參與者在等待超時後，會繼續進行事務的提交。
優點：相對於二階段提交，此方法有點在於降低了參與者阻塞的範圍，並且能夠在出現單點故障後繼續達成一致。
缺點：在參與者接受到precommit訊息後，出現網路分割槽（部分通訊不可用），此時協調者所在的節點和參與者無法進行通訊，此時參與者會依然提交事務，會導致資料的不一致。
9. sagas事務模型
長時間執行的事務（long-running-transaction）---比較新
該模型核心思想就是拆分分布式系統中的長事務為多個短事務，或者叫多個本地事務，然後由 sagas 工作流引擎負責協調，如果整個流程正常結束，那麼就算是業務成功完成，如果在這過程中實現失敗，那麼sagas工作流引擎就會以相反的順序呼叫補償操作，重新進行業務回滾。
10. 總結
分布式事務用在需要嚴格保證一致性的地方，比如資金方便；分布式事務不是越多越好的，**複雜，效能變差，系統吞吐量下降，效能**。大多數情況是不需要用分布式事務的，可以直接通過監控（郵件，簡訊），記日誌，事後定位、排查和解決、修復資料。此時的成本也比全部使用分布式事務的成本要低。
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...
分布式事務 分布式事務的實現
如果在多個服務中需要對不同的資料庫進行操作。因為不同服務操作的資料庫都不同，所以保證在同乙個事務中完成操作顯然是不科學的。那實現分布式事務的思想 1 方法入口，建立一條日誌記錄，狀態定義為初始狀態，即儲存本條日誌記錄 可以儲存在資料庫中，也可以寫出到本地磁碟檔案 2 可以在非同步執行緒或在定時任務中...
分布式之分布式事務
被人問到分布式事務，之前學rabbitmq 的時候學到過rabbitmq 高階的事務，因為沒有用過，所有沒有回答好。這裡總結一下。1.單機版事務。事務的四大特性 acid a.原子性 b.一致性 c.隔離性 d.永續性 單機事務可以通過設定事務的隔離級別 參見spring 的事務隔離級別 2.分布式...