事務基礎概念

事務的隔離級別：讀未提交、讀已提交、可重複讀、序列化
mysql預設的是可重複讀
髒讀：一個事務讀取到另一個事務未提交的資料
幻讀：一個事務讀取到另一個事務提交的insert資料
不可重複讀：同一事務中後續讀取到的是另一個事務已提交的更新資料；
可重複讀：冪等性，同一個事務中多次讀取的資料一致。
事務的傳播行為：
預設：@Transactional(propagation=Propagation.REQUIRED) 如果有事務，加入事務，如果沒有則開啟一個新的事務
Propagation.NOT_SUPPORTED 不為該方法開啟事務
Propagation.REQUIRES_NEW 不管是否存在事務，都建立一個新的事務，原來的先掛起，執行完新事務繼續執行老的事務

Transaction註解中的引數介紹
rollbackFor 當方法中丟擲指定陣列中的異常時，則進行回滾

分散式事務

分散式系統的核心就是處理各種異常情況，這也是分散式系統複雜的地方，所以我們在做分散式系統的時候，最先考慮的就是這種情況。這些異常可能有 機器宕機、網路異常、訊息丟失、訊息亂序、資料錯誤、不可靠的TCP、儲存資料丟失、其他異常等等。

單個數據庫的效能產生瓶頸的時候，我們可能會對資料庫進行分割槽，再想保證叢集的ACID幾乎是很難達到，CAP定理提出web服務無法同時滿足一致性、可用性和分割槽容錯性。
分散式系統中，可用性的重要程式比一致性要高，BASE理論是對CAP定理進行進一步擴充，BASE理論是對CAP中的一致性和可用性進行一個權衡的結果。理論的核心思想就是：我們無法做到強一致，但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性（Eventual consistency）。

分散式事務解決方案

1、兩階段提交(2PC)：犧牲可用性換取強一致性，不適合高併發高效能場景。
第一階段是表決階段，所有參與者都將本事務能否成功的資訊反饋發給協調者；第二階段是執行階段，協調者根據所有參與者的反饋，通知所有參與者，步調一致地在所有分支上提交或者回滾。
2、補償事務(TCC)：一致性較差，需要程式設計師寫一些補償程式碼，一些業務場景下，TCC不好定義和處理。
3、本地事務表(非同步確保)：基本思路是將本地操作和傳送訊息放在一個事務中，保證本地操作和訊息傳送要麼兩者都成功或者都失敗，
避免了分散式事務，實現了最終一致性，但是會把訊息表耦合到業務系統，如果沒有分裝好的解決方案，還有一些雜活要處理。
4、mq事務訊息

：實現了最終一致性，不需要依賴本地資料庫事務。主流mq不支援，rocketmq事務訊息部分未開源。
mq事務訊息需要考慮的問題：
支付寶向餘額寶轉賬，支付寶扣款後未提交時先發送訊息到中介軟體，中介軟體不會立即傳送，而是等待扣款事務提交成功後收到訊息確認傳送指令才會傳送。
業務與訊息解耦：新增一個訊息確認系統，定時去支付寶系統查詢這個訊息的狀態，收到確認傳送指令後才傳送。
訊息重複投遞即重複消費
解決方法很簡單，在餘額寶這邊增加訊息應用狀態表（message_apply），通俗來說就是個賬本，用於記錄訊息的消費情況，每次來一個訊息，在真正執行之前，先去訊息應用狀態表中查詢一遍，如果找到說明是重複訊息，丟棄即可，如果沒找到才執行，同時插入到訊息應用狀態表（同一事務）。