寫在前面
寫這篇文章的背景是有個跟我關係不錯的小夥伴去某大型網際網路公司面試，面試官問了他關於分散式事務的問題，不巧的是他確實對分散式事務掌握的不是很深入，面試的結果挺遺憾的。不過，這位小夥伴還是挺樂觀的，讓我寫寫關於【分散式事務】的系列文章，他想提升自己關於分散式事務的短板，那我就寫一個【分散式事務】專題吧，專題的內容計劃是從原理、框架原始碼到企業級實現，這篇文章也算是整個專題的開篇吧。希望能夠為小夥伴們帶來實質性的幫助。
本地事務
本地事務流程
在介紹分散式事務之前，我們先來看看本地事務。首先，我們先來一張圖。
由上圖，我們可以看出，本地事務由資源管理器（比如DBMS，資料庫管理系統）在本地進行管理。
本地事務的優缺點
本地事務具備相應的優點，也有其不足。
優點：
- 支援嚴格的ACID屬性。
- 可靠，事務實現的效率高（只是在本地操作）。
- 可以只在RM（資源管理器）中操作事務。
- 程式設計模型簡單。
缺點：
- 缺乏分散式事務的處理能力。
- 資料隔離的最小單元由RM（資源管理器決定），開發人員無法決定資料隔離的最小單元。比如：資料庫中的一條記錄等。
ACID屬性
說起事務，我們不得不提的就是事務的ACID屬性。
- A（Atomic）：原子性，構成事務的所有操作，要麼都執行完成，要麼全部不執行，不可能出現部分成功部分失
敗的情況。 - C（Consistency）：一致性，在事務執行前後，資料庫的一致性約束沒有被破壞。比如：張三向李四轉100元，
轉賬前和轉賬後的資料的正確狀態叫作一致性，如果出現張三轉出100元，李四賬戶沒有增加100元這就出現了數
據錯誤，就沒有達到一致性。 - I（Isolation）：隔離性，資料庫中的事務一般都是併發的，隔離性是指併發的兩個事務的執行互不干擾，一個事
務不能看到其他事務執行過程的中間狀態。通過配置事務隔離級別可以避髒讀、重複讀等問題。 - D（Durability）：永續性，事務完成之後，該事務對資料的更改會被持久化到資料庫，且不會被回滾。
分散式事務
隨著業務的快速發展，網站系統往往由單體架構逐漸演變為分散式、微服務架構，而對於資料庫則由單機資料庫架構向分散式資料庫架構轉變。此時，我們會將一個大的應用系統拆分為多個可以獨立部署的應用服務，需要各個服務之間進行遠端協作才能完成事務操作。
我們可以使用下圖來表示剛開始我們系統的單體架構。
上圖中，我們將同一個專案中的不同模組組織成不同的包來進行管理，所有的程式程式碼仍然是放在同一個專案中。
後續由於業務的發展，我們將其擴充套件為分散式、微服務架構。此時，我們將一個大的專案拆分為一個個小的可以獨立部署的微服務，每個微服務都有自己的資料庫，如下所示。
又比如，在我們的程式中，經常會在同一個事務中執行類似如下的程式碼來完成我們的需求。
@Transactional(rollbackFor = Exception.class)
public void submitOrder() {
orderDao.update(); // 更新訂單資訊
accountService.update(); // 修改資金賬戶的金額
pointService.update(); // 修改積分
accountingService.insert(); // 插入交易流水
merchantNotifyService.notify(); // 通知支付結果
}
上述程式碼中的業務，僅僅在submitOrder()方法上新增了一個@Transactional註解，這能夠在分散式場景下避免分散式事務的問題嗎？很顯然是不行的。
如果上述程式碼所對應的：訂單資訊、資金賬戶資訊、積分資訊、交易流水等資訊分別儲存在不同的資料裡，而支付完成後，通知的目標系統的資料同樣是儲存在不同的資料庫中。此時就會產生分散式事務問題。
分散式事務產生的場景
跨JVM程式
當我們將單體專案拆分為分散式、微服務專案之後，各個服務之間通過遠端REST或者RPC呼叫來協同完成業務操作。典型的場景就是：商城系統中的訂單微服務和庫存微服務，使用者在下單時會訪問訂單微服務，訂單微服務在生成訂單記錄時，會呼叫庫存微服務來扣減庫存。各個微服務是部署在不同的JVM程式中的，此時，就會產生因跨JVM程式而導致的分散式事務問題。
跨資料庫例項
單體系統訪問多個資料庫例項，也就是跨資料來源訪問時會產生分散式事務。例如，我們的系統中的訂單資料庫和交易資料庫是放在不同的資料庫例項中，當使用者發起退款時，會同時操作使用者的訂單資料庫和交易資料庫，在交易資料庫中執行退款操作，在訂單資料庫中將訂單的狀態變更為已退款。由於資料分佈在不同的資料庫例項，需要通過不同的資料庫連線會話來運算元據庫中的資料，此時，就產生了分散式事務。
多服務單資料庫
多個微服務訪問同一個資料庫。例如，訂單微服務和庫存微服務訪問同一個資料庫也會產生分散式事務，原因是：多個微服務訪問同一個資料庫，本質上也是通過不同的資料庫會話來運算元據庫，此時就會產生分散式事務。
注意：跨資料庫例項場景和多服務單資料庫場景，本質上都是因為會產生不同的資料庫會話來運算元據庫中的資料，進而產生分散式事務。這兩種場景是大家比較容易忽略的。
分散式事務解決方案
知道了分散式事務產生的場景後，接下來，我們就聊聊分散式事務具體有哪些解決方案。
2PC方案
2PC即兩階段提交協議，是將整個事務流程分為兩個階段，準備階段（Prepare phase）、提交階段（commit
phase），2是指兩個階段，P是指準備階段，C是指提交階段。
這裡，我們用MySQL資料庫舉例，MySQL資料庫支援兩階段提交協議，可以分為成功和失敗兩種情況。
成功情況
失敗情況
具體流程如下：
準備階段（Prepare phase）： 事務管理器給每個參與者傳送Prepare訊息，每個資料庫參與者在本地執行事
務，並寫本地的Undo/Redo日誌，此時事務沒有提交。
（Undo日誌是記錄修改前的資料，用於資料庫回滾，Redo日誌是記錄修改後的資料，用於提交事務後寫入數
據檔案）
提交階段（commit phase）： 如果事務管理器收到了參與者的執行失敗或者超時訊息時，直接給每個參與者
傳送回滾(Rollback)訊息；否則，傳送提交(Commit)訊息；參與者根據事務管理器的指令執行提交或者回滾操
作，並釋放事務處理過程中使用的鎖資源。
使用2PC方案時，需要注意的是：必須在最後階段釋放鎖資源。
可靠訊息最終一致性方案
可靠訊息最終一致性方案是指當事務發起方執行完成本地事務後併發出一條訊息，事務參與方(訊息消費者)一定能
夠接收訊息並處理事務成功，此方案強調的是隻要訊息發給事務參與方最終事務要達到一致。
事務發起方（訊息生產方）將訊息發給訊息中介軟體，事務參與方從訊息中介軟體接收訊息，事務發起方和訊息中介軟體
之間，事務參與方（訊息消費方）和訊息中介軟體之間都是通過網路通訊，由於網路通訊的不確定性會導致分散式事
務問題。 所以，我們在具體方案中會引入訊息確認服務和訊息恢復服務。
使用可靠訊息最終一致性方案時需要注意幾個問題：
- 本地事務與訊息傳送的原子性問題。
- 事務參與方接收訊息的可靠性問題。
- 訊息重複消費的問題（需要實現冪等）。
TCC方案
TCC分為三個階段：
- Try 階段 是做業務檢查(一致性)及資源預留(隔離)，此階段僅是一個初步操作，它和後續的Confirm 一起才能
真正構成一個完整的業務邏輯。 - Confirm 階段 是做確認提交，Try階段所有分支事務執行成功後開始執行 Confirm。通常情況下，採用TCC則
認為 Confirm階段是不會出錯的。即：只要Try成功，Confirm一定成功。若Confirm階段真的出錯了，需引
入重試機制或人工處理。 - Cancel 階段 是在業務執行錯誤需要回滾的狀態下執行分支事務的業務取消，預留資源釋放。通常情況下，採
用TCC則認為Cancel階段也是一定成功的。若Cancel階段真的出錯了，需引入重試機制或人工處理。
使用TCC分散式解決方案時需要注意空回滾、冪等、懸掛等問題。
最大努力通知型方案
此種方案主要用於多個不同系統之前保證資料的最終一致性，大體如下圖所示。
使用最大努力通知型方案需要注意冪等和資料的回查操作。
好了，今天就到這兒吧，後續我們會針對每種分散式事務解決方案進行具體介紹，下期見！！
開源專案
最後，我開源了基於訊息最終一致性的分散式事務框架mykit-transaction-message。框架中有很完善的demo示例。
github：https://github.com/sunshinelyz/mykit-transaction-message
gitee：https://gitee.com/binghe001/mykit-transaction-message