分布式事務：當我們進行操作的時候不是操作相同的資料庫，那麼事務的連線也就不一樣。
這個時候要解決兩個資料庫的事務的原子性。那麼就需要使用分布式事務。
方案一：如果使用同乙個spring容器管理了多個資料庫，那麼就可以使用spring jta解決分布式事務，
這個只是資料庫層面的乙個分布式，服務並沒有分布式。
方案二：如果使用的不同的spring容器，就是說我們的專案是分布式。比如我們的servicea要運算元據庫a，
serviceb運算元據庫b，並且servicea和serviceb在不同的子系統中，但是現在需要在servicea中呼叫
serviceb完成業務，那麼如何解決兩者之間分布式提交。
答：目前比較流行的解決方法是結合mq訊息中介軟體並且實現的事務最終一致性,這裡採用rocketmq訊息
提供的事務訊息機制(準備提交-mq確認可以接收-確認傳送訊息)可以保證本地事務和訊息傳送事務要麼一
起成功，要麼一起失敗，同時提供超時機制重**送訊息，並且可以解決訊息重複的問題(記錄訊息id的方
式，保證重**生的訊息的id與第一次傳送的訊息id一致)，但是無法保證訊息消費者端事務一定成功提交，
這裡一般需要在生產者訊息傳送成功之後記錄一條事務訊息到redis快取中，redis快取記錄了訊息事務的id
還有訊息事務的狀態以及相關必要資訊，如果消費者事務提交成功那麼修改該訊息在redis中的狀態，如果
消費者事務失敗，redis狀態將不能得到改變，那麼我們就可以在後台從redis中得到失敗的事務，然後再由
人工進行處理，這樣就可以保證事務的最終一致性。
案例說明：現我給你轉賬1000，那麼我就應該扣1000，而你要加1000，但是扣款的服務在系統a
的servicea中，而加款的服務在系統b的serviceb中，這個時候在servicea呼叫serviceb
完成轉賬過程。事務執行過程
1). servicea開始
2). rocketmq傳送一條預處理訊息傳送給mq訊息佇列一條prepared訊息。
(成功則往下執行，不成功則事務失敗。整個流程結束)
3). 執行servicea的本地事務，執行我的扣款操作。
4). 向redis中新增一條事務訊息，採用hash來儲存。hash中的key是當前事務訊息的id。
value儲存了事務訊息的狀態，還有相關必要的資料。
5). 執行確認訊息傳送，確認訊息傳送面臨的問題：訊息可能傳送不成功，這個時候rocketmq提供超時
機制，如果訊息傳送超時那麼可以在嘗試重新傳送幾次，超過指定次數，訊息傳送失敗，事務回滾。如果
訊息傳送成功，可能會面臨訊息重**送的問題，那麼採用日誌記錄已經被消費的訊息的id，防止重複消費。
這樣就能保證訊息傳送和本地事務能夠同時成功或者同時失敗。如果訊息傳送成功那麼扣款事務也一定提交，
而不再考慮加款事務是否成功，因為後面就算加款事務沒有成功，還有人工處理。
6). 訊息成功傳送之後，消費者接收到訊息，成功提交事務之後，你的加款操作，修改redis中對應訊息記錄
的狀態。但是存在訊息沒有被消費者收到或者消費者事務失敗的問題，這個時候人工處理根據redis中的事務
訊息，找到還沒有成功的事務手動處理。保證事務的最終一致性。
7). 事務結束。
事務 分布式事務解決方案
事務acid特性 事務隔離級別 指的是讀和寫同時出現時出現的資料不一致問題。事務的一致性問題 存在問題問題描述 髒讀 dirty read 針對的是單條資料。即乙個更新操作a修改了某一條資料，但尚未提交該事務，此時另乙個讀操作b來查詢該條資料，讀到的是修改後的但尚未提交的資料。不可重複讀 unrep...
分布式事務解決方案
一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性，需要業務系統結合mq訊息中介軟體實現，在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性，分為三個階段tryi...
分布式事務解決方案
當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務化。比如原來單機...