[[346590]]

作者個人研發(fā)的在高并發(fā)場景下，提供的簡單、穩(wěn)定、可擴展的延遲消息隊列框架，具有精準的定時任務和延遲隊列處理功能。自開源半年多以來，已成功為十幾家中小型企業(yè)提供了精準定時調(diào)度方案，經(jīng)受住了生產(chǎn)環(huán)境的考驗。為使更多童鞋受益，現(xiàn)給出開源框架地址：https://github.com/sunshinelyz/mykit-delay

PS: 歡迎各位Star源碼，也可以pr你牛逼哄哄的代碼。

寫在前面

寫這篇文章的背景是有個跟我關(guān)系不錯的小伙伴去某大型互聯(lián)網(wǎng)公司面試，面試官問了他關(guān)于分布式事務的問題，不巧的是他確實對分布式事務掌握的不是很深入，面試的結(jié)果挺遺憾的。不過，這位小伙伴還是挺樂觀的，讓我寫寫關(guān)于【分布式事務】的系列文章，想提升自己關(guān)于分布式事務的短板，那我就寫一個【分布式事務】專題吧，專題的內(nèi)容計劃是從原理、框架源碼到企業(yè)級實現(xiàn)，這篇文章也算是整個專題的開篇吧。希望能夠為小伙伴們帶來實質(zhì)性的幫助。

本地事務

本地事務流程

在介紹分布式事務之前，我們先來看看本地事務。首先，我們先來一張圖。

由上圖，我們可以看出，本地事務由資源管理器(比如DBMS，數(shù)據(jù)庫管理系統(tǒng))在本地進行管理。

本地事務的優(yōu)缺點

本地事務具備相應的優(yōu)點，也有其不足。

優(yōu)點：

• 支持嚴格的ACID屬性。
• 可靠，事務實現(xiàn)的效率高(只是在本地操作)。
• 可以只在RM(資源管理器)中操作事務。
• 編程模型簡單。

缺點：

• 缺乏分布式事務的處理能力。
• 數(shù)據(jù)隔離的最小單元由RM(資源管理器決定)，開發(fā)人員無法決定數(shù)據(jù)隔離的最小單元。比如：數(shù)據(jù)庫中的一條記錄等。

ACID屬性

說起事務，我們不得不提的就是事務的ACID屬性。

• A(Atomic)：原子性，構(gòu)成事務的所有操作，要么都執(zhí)行完成，要么全部不執(zhí)行，不可能出現(xiàn)部分成功部分失 敗的情況。
• C(Consistency)：一致性，在事務執(zhí)行前后，數(shù)據(jù)庫的一致性約束沒有被破壞。比如：張三向李四轉(zhuǎn)100元， 轉(zhuǎn)賬前和轉(zhuǎn)賬后的數(shù)據(jù)的正確狀態(tài)叫作一致性，如果出現(xiàn)張三轉(zhuǎn)出100元，李四賬戶沒有增加100元這就出現(xiàn)了數(shù) 據(jù)錯誤，就沒有達到一致性。
• I(Isolation)：隔離性，數(shù)據(jù)庫中的事務一般都是并發(fā)的，隔離性是指并發(fā)的兩個事務的執(zhí)行互不干擾，一個事 務不能看到其他事務運行過程的中間狀態(tài)。通過配置事務隔離級別可以避臟讀、重復讀等問題。
• D(Durability)：持久性，事務完成之后，該事務對數(shù)據(jù)的更改會被持久化到數(shù)據(jù)庫，且不會被回滾。

分布式事務

隨著業(yè)務的快速發(fā)展，網(wǎng)站系統(tǒng)往往由單體架構(gòu)逐漸演變?yōu)榉植际健⑽⒎占軜?gòu)，而對于數(shù)據(jù)庫則由單機數(shù)據(jù)庫架構(gòu)向分布式數(shù)據(jù)庫架構(gòu)轉(zhuǎn)變。此時，我們會將一個大的應用系統(tǒng)拆分為多個可以獨立部署的應用服務，需要各個服務之間進行遠程協(xié)作才能完成事務操作。

我們可以使用下圖來表示剛開始我們系統(tǒng)的單體架構(gòu)。

上圖中，我們將同一個項目中的不同模塊組織成不同的包來進行管理，所有的程序代碼仍然是放在同一個項目中。

后續(xù)由于業(yè)務的發(fā)展，我們將其擴展為分布式、微服務架構(gòu)。此時，我們將一個大的項目拆分為一個個小的可以獨立部署的微服務，每個微服務都有自己的數(shù)據(jù)庫，如下所示。

又比如，在我們的程序中，經(jīng)常會在同一個事務中執(zhí)行類似如下的代碼來完成我們的需求。

@Transactional(rollbackFor = Exception.class) 
public void submitOrder() { 
    orderDao.update(); // 更新訂單信息 
    accountService.update(); // 修改資金賬戶的金額 
    pointService.update(); //  修改積分 
    accountingService.insert(); // 插入交易流水 
    merchantNotifyService.notify(); // 通知支付結(jié)果 
} 

上述代碼中的業(yè)務，僅僅在submitOrder()方法上添加了一個@Transactional注解，這能夠在分布式場景下避免分布式事務的問題嗎?很顯然是不行的。

如果上述代碼所對應的：訂單信息、資金賬戶信息、積分信息、交易流水等信息分別存儲在不同的數(shù)據(jù)里，而支付完成后，通知的目標系統(tǒng)的數(shù)據(jù)同樣是存儲在不同的數(shù)據(jù)庫中。此時就會產(chǎn)生分布式事務問題。

分布式事務產(chǎn)生的場景

跨JVM進程

當我們將單體項目拆分為分布式、微服務項目之后，各個服務之間通過遠程REST或者RPC調(diào)用來協(xié)同完成業(yè)務操作。典型的場景就是：商城系統(tǒng)中的訂單微服務和庫存微服務，用戶在下單時會訪問訂單微服務，訂單微服務在生成訂單記錄時，會調(diào)用庫存微服務來扣減庫存。各個微服務是部署在不同的JVM進程中的，此時，就會產(chǎn)生因跨JVM進程而導致的分布式事務問題。

跨數(shù)據(jù)庫實例

單體系統(tǒng)訪問多個數(shù)據(jù)庫實例，也就是跨數(shù)據(jù)源訪問時會產(chǎn)生分布式事務。例如，我們的系統(tǒng)中的訂單數(shù)據(jù)庫和交易數(shù)據(jù)庫是放在不同的數(shù)據(jù)庫實例中，當用戶發(fā)起退款時，會同時操作用戶的訂單數(shù)據(jù)庫和交易數(shù)據(jù)庫，在交易數(shù)據(jù)庫中執(zhí)行退款操作，在訂單數(shù)據(jù)庫中將訂單的狀態(tài)變更為已退款。由于數(shù)據(jù)分布在不同的數(shù)據(jù)庫實例，需要通過不同的數(shù)據(jù)庫連接會話來操作數(shù)據(jù)庫中的數(shù)據(jù)，此時，就產(chǎn)生了分布式事務。

多服務單數(shù)據(jù)庫

多個微服務訪問同一個數(shù)據(jù)庫。例如，訂單微服務和庫存微服務訪問同一個數(shù)據(jù)庫也會產(chǎn)生分布式事務，原因是：多個微服務訪問同一個數(shù)據(jù)庫，本質(zhì)上也是通過不同的數(shù)據(jù)庫會話來操作數(shù)據(jù)庫，此時就會產(chǎn)生分布式事務。

注意：跨數(shù)據(jù)庫實例場景和多服務單數(shù)據(jù)庫場景，本質(zhì)上都是因為會產(chǎn)生不同的數(shù)據(jù)庫會話來操作數(shù)據(jù)庫中的數(shù)據(jù)，進而產(chǎn)生分布式事務。這兩種場景是大家比較容易忽略的。

分布式事務解決方案

知道了分布式事務產(chǎn)生的場景后，接下來，我們就聊聊分布式事務具體有哪些解決方案。

2PC方案

2PC即兩階段提交協(xié)議，是將整個事務流程分為兩個階段，準備階段(Prepare phase)、提交階段(commit phase)，2是指兩個階段，P是指準備階段，C是指提交階段。

這里，我們用MySQL數(shù)據(jù)庫舉例，MySQL數(shù)據(jù)庫支持兩階段提交協(xié)議，可以分為成功和失敗兩種情況。

成功情況

失敗情況

具體流程如下：

準備階段(Prepare phase)： 事務管理器給每個參與者發(fā)送Prepare消息，每個數(shù)據(jù)庫參與者在本地執(zhí)行事 務，并寫本地的Undo/Redo日志，此時事務沒有提交。(Undo日志是記錄修改前的數(shù)據(jù)，用于數(shù)據(jù)庫回滾，Redo日志是記錄修改后的數(shù)據(jù)，用于提交事務后寫入數(shù) 據(jù)文件)

提交階段(commit phase)： 如果事務管理器收到了參與者的執(zhí)行失敗或者超時消息時，直接給每個參與者 發(fā)送回滾(Rollback)消息;否則，發(fā)送提交(Commit)消息;參與者根據(jù)事務管理器的指令執(zhí)行提交或者回滾操 作，并釋放事務處理過程中使用的鎖資源。

使用2PC方案時，需要注意的是：必須在最后階段釋放鎖資源。

可靠消息最終一致性方案

可靠消息最終一致性方案是指當事務發(fā)起方執(zhí)行完成本地事務后并發(fā)出一條消息，事務參與方(消息消費者)一定能 夠接收消息并處理事務成功，此方案強調(diào)的是只要消息發(fā)給事務參與方最終事務要達到一致。

事務發(fā)起方(消息生產(chǎn)方)將消息發(fā)給消息中間件，事務參與方從消息中間件接收消息，事務發(fā)起方和消息中間件 之間，事務參與方(消息消費方)和消息中間件之間都是通過網(wǎng)絡通信，由于網(wǎng)絡通信的不確定性會導致分布式事 務問題。 所以，我們在具體方案中會引入消息確認服務和消息恢復服務。

使用可靠消息最終一致性方案時需要注意幾個問題：

• 本地事務與消息發(fā)送的原子性問題。
• 事務參與方接收消息的可靠性問題。
• 消息重復消費的問題(需要實現(xiàn)冪等)。

TCC方案

TCC分為三個階段：

• Try 階段 是做業(yè)務檢查(一致性)及資源預留(隔離)，此階段僅是一個初步操作，它和后續(xù)的Confirm 一起才能 真正構(gòu)成一個完整的業(yè)務邏輯。
• Confirm 階段 是做確認提交，Try階段所有分支事務執(zhí)行成功后開始執(zhí)行 Confirm。通常情況下，采用TCC則 認為 Confirm階段是不會出錯的。即：只要Try成功，Confirm一定成功。若Confirm階段真的出錯了，需引 入重試機制或人工處理。
• Cancel 階段 是在業(yè)務執(zhí)行錯誤需要回滾的狀態(tài)下執(zhí)行分支事務的業(yè)務取消，預留資源釋放。通常情況下，采 用TCC則認為Cancel階段也是一定成功的。若Cancel階段真的出錯了，需引入重試機制或人工處理。

使用TCC分布式解決方案時需要注意空回滾、冪等、懸掛等問題。

最大努力通知型方案

此種方案主要用于多個不同系統(tǒng)之前保證數(shù)據(jù)的最終一致性，大體如下圖所示。

使用最大努力通知型方案需要注意冪等和數(shù)據(jù)的回查操作。

好了，今天就到這兒吧，后續(xù)我們會針對每種分布式事務解決方案進行具體介紹，下期見!!

本文轉(zhuǎn)載自微信公眾號「冰河技術(shù)」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系冰河技術(shù)公眾號。