本地事務：以往的單體系統中，一般都是乙個資料來源例項共同訪問乙個資料庫，這種情況下只有乙個資料庫連線，事務操作在同乙個連線裡面，可以做到一起回滾/提交，也就是事務的acid原理。
分布式事務：由於網際網路的發展，系統架構由單體系統演進為分布式/微服務系統，在微服務架構體系下，不同的服務可能會有對應的資料庫，此時資料庫之間都是不同的資料來源例項，也就是不是同乙個jdbc連線，事務之間無法做到同時提交/回滾。比如張三給李四轉賬100元，張三（銀行服務1）先更新餘額-100，然後遠端呼叫李四（銀行服務2）更新餘額+100，此時若張三所在微服務發生異常回滾，張三餘額沒有變動，而李四所在服務沒有回滾，相當於李四平白多出了100。這就是分布式事務，導致資料不一致問題。
分布式事務產生的場景：
其實分布式事務並不是只有在分布式和微服務架構上才會產生，分布式事務產生的原因其實就是多個datasource連線操作不同的資料庫導致的。單體系統也是有可能產生分布式事務的。
1. 單體系統：比如在乙個mysql中建立兩個資料庫，在乙個事務方法裡面操作兩個資料庫，兩者之間不能一起提交或回滾操作。
2.微服務：比如訂單和庫存服務都有各自對應資料庫，同時操作兩個資料庫也不能做到一起提交或回滾。
3.微服務：訂單和庫存服務使用同乙個資料庫，此時仍然會有問題，因為兩個服務是跨jvm程序的，不同的jvm程序之間的資料來源連線是互不干擾的。
常見的有解決方案：
2pc:兩段提交，ali的seata就是基於2pc的，只不過seata並不需要資料庫支援xa協議，並且效率更高，在第一階段就釋放了資源鎖定，具體是通過undo_log表記錄，然後反向sql操作來實現回滾。
tcc：事務補償，需要定義try,commit,cancel三個方法，業務成本相對偏高。
可靠訊息最終一致性：通過rocketmq的事務訊息可以實現。
最大努力通知：比如支付模組呼叫第三方支付介面，此時第三方支付會通過訊息機制盡最大努力重複通知，若是無法通知到結果，可以主動呼叫介面查詢結果。
事務 分布式事務解決方案
事務acid特性 事務隔離級別 指的是讀和寫同時出現時出現的資料不一致問題。事務的一致性問題 存在問題問題描述 髒讀 dirty read 針對的是單條資料。即乙個更新操作a修改了某一條資料，但尚未提交該事務，此時另乙個讀操作b來查詢該條資料，讀到的是修改後的但尚未提交的資料。不可重複讀 unrep...
分布式事務解決方案
一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性，需要業務系統結合mq訊息中介軟體實現，在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性，分為三個階段tryi...
分布式事務解決方案
當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務化。比如原來單機...