Java中TCC分布式事務(wù)的實(shí)現(xiàn)原理

這篇文章給大家分享的是有關(guān)Java中TCC分布式事務(wù)的實(shí)現(xiàn)原理的內(nèi)容。小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過(guò)來(lái)看看吧。

Java的特點(diǎn)有哪些

Java的特點(diǎn)有哪些 1.Java語(yǔ)言作為靜態(tài)面向?qū)ο缶幊陶Z(yǔ)言的代表，實(shí)現(xiàn)了面向?qū)ο罄碚?，允許程序員以優(yōu)雅的思維方式進(jìn)行復(fù)雜的編程。 2.Java具有簡(jiǎn)單性、面向?qū)ο?、分布式、安全性、平臺(tái)獨(dú)立與可移植性、動(dòng)態(tài)性等特點(diǎn)。 3.使用Java可以編寫桌面應(yīng)用程序、Web應(yīng)用程序、分布式系統(tǒng)和嵌入式系統(tǒng)應(yīng)用程序等。

概述

之前網(wǎng)上看到很多寫分布式事務(wù)的文章，不過(guò)大多都是將分布式事務(wù)各種技術(shù)方案簡(jiǎn)單介紹一下。很多朋友看了還是不知道分布式事務(wù)到底怎么回事，在項(xiàng)目里到底如何使用。

所以這篇文章，就用大白話+手工繪圖，并結(jié)合一個(gè)電商系統(tǒng)的案例實(shí)踐，來(lái)給大家講清楚到底什么是 TCC 分布式事務(wù)。

業(yè)務(wù)場(chǎng)景介紹

咱們先來(lái)看看業(yè)務(wù)場(chǎng)景，假設(shè)你現(xiàn)在有一個(gè)電商系統(tǒng)，里面有一個(gè)支付訂單的場(chǎng)景。

那對(duì)一個(gè)訂單支付之后，我們需要做下面的步驟：

• 更改訂單的狀態(tài)為“已支付”

• 扣減商品庫(kù)存

• 給會(huì)員增加積分

• 創(chuàng)建銷售出庫(kù)單通知倉(cāng)庫(kù)發(fā)貨

這是一系列比較真實(shí)的步驟，無(wú)論大家有沒(méi)有做過(guò)電商系統(tǒng)，應(yīng)該都能理解。

進(jìn)一步思考

好，業(yè)務(wù)場(chǎng)景有了，現(xiàn)在我們要更進(jìn)一步，實(shí)現(xiàn)一個(gè) TCC 分布式事務(wù)的效果。

什么意思呢？也就是說(shuō)，[1] 訂單服務(wù)-修改訂單狀態(tài)，[2] 庫(kù)存服務(wù)-扣減庫(kù)存，[3] 積分服務(wù)-增加積分，[4] 倉(cāng)儲(chǔ)服務(wù)-創(chuàng)建銷售出庫(kù)單。

上述這幾個(gè)步驟，要么一起成功，要么一起失敗，必須是一個(gè)整體性的事務(wù)。

舉個(gè)例子，現(xiàn)在訂單的狀態(tài)都修改為“已支付”了，結(jié)果庫(kù)存服務(wù)扣減庫(kù)存失敗。那個(gè)商品的庫(kù)存原來(lái)是 100 件，現(xiàn)在賣掉了 2 件，本來(lái)應(yīng)該是 98 件了。

結(jié)果呢？由于庫(kù)存服務(wù)操作數(shù)據(jù)庫(kù)異常，導(dǎo)致庫(kù)存數(shù)量還是 100。這不是在坑人么，當(dāng)然不能允許這種情況發(fā)生了！

但是如果你不用 TCC 分布式事務(wù)方案的話，就用個(gè) Spring Cloud 開發(fā)這么一個(gè)微服務(wù)系統(tǒng)，很有可能會(huì)干出這種事兒來(lái)。

我們來(lái)看看下面的這個(gè)圖，直觀的表達(dá)了上述的過(guò)程：

所以說(shuō)，我們有必要使用 TCC 分布式事務(wù)機(jī)制來(lái)保證各個(gè)服務(wù)形成一個(gè)整體性的事務(wù)。

上面那幾個(gè)步驟，要么全部成功，如果任何一個(gè)服務(wù)的操作失敗了，就全部一起回滾，撤銷已經(jīng)完成的操作。

比如說(shuō)庫(kù)存服務(wù)要是扣減庫(kù)存失敗了，那么訂單服務(wù)就得撤銷那個(gè)修改訂單狀態(tài)的操作，然后得停止執(zhí)行增加積分和通知出庫(kù)兩個(gè)操作。

說(shuō)了那么多，老規(guī)矩，給大家上一張圖，大伙兒順著圖來(lái)直觀的感受一下：

落地實(shí)現(xiàn) TCC 分布式事務(wù)

那么現(xiàn)在到底要如何來(lái)實(shí)現(xiàn)一個(gè) TCC 分布式事務(wù)，使得各個(gè)服務(wù)，要么一起成功？要么一起失敗呢？

大家稍安勿躁，我們這就來(lái)一步一步的分析一下。咱們就以一個(gè) Spring Cloud 開發(fā)系統(tǒng)作為背景來(lái)解釋。

TCC 實(shí)現(xiàn)階段一：Try

首先，訂單服務(wù)那兒，它的代碼大致來(lái)說(shuō)應(yīng)該是這樣子的：

public class OrderService {

    // 庫(kù)存服務(wù)
    @Autowired
    private InventoryService inventoryService;

    // 積分服務(wù)
    @Autowired
    private CreditService creditService;

    // 倉(cāng)儲(chǔ)服務(wù)
    @Autowired
    private WmsService wmsService;

    // 對(duì)這個(gè)訂單完成支付
    public void pay(){
        //對(duì)本地的的訂單數(shù)據(jù)庫(kù)修改訂單狀態(tài)為"已支付"
        orderDAO.updateStatus(OrderStatus.PAYED);

        //調(diào)用庫(kù)存服務(wù)扣減庫(kù)存
        inventoryService.reduceStock();

        //調(diào)用積分服務(wù)增加積分
        creditService.addCredit();

        //調(diào)用倉(cāng)儲(chǔ)服務(wù)通知發(fā)貨
        wmsService.saleDelivery();
    }
}

如果你之前看過(guò) Spring Cloud 架構(gòu)原理那篇文章，同時(shí)對(duì) Spring Cloud 有一定的了解的話，應(yīng)該是可以理解上面那段代碼的。

其實(shí)就是訂單服務(wù)完成本地?cái)?shù)據(jù)庫(kù)操作之后，通過(guò) Spring Cloud 的 Feign 來(lái)調(diào)用其他的各個(gè)服務(wù)罷了。

但是光是憑借這段代碼，是不足以實(shí)現(xiàn) TCC 分布式事務(wù)的??？！兄弟們，別著急，我們對(duì)這個(gè)訂單服務(wù)修改點(diǎn)兒代碼好不好。

首先，上面那個(gè)訂單服務(wù)先把自己的狀態(tài)修改為：OrderStatus.UPDATING。

這是啥意思呢？也就是說(shuō)，在 pay() 那個(gè)方法里，你別直接把訂單狀態(tài)修改為已支付??！你先把訂單狀態(tài)修改為 UPDATING，也就是修改中的意思。

這個(gè)狀態(tài)是個(gè)沒(méi)有任何含義的這么一個(gè)狀態(tài)，代表有人正在修改這個(gè)狀態(tài)罷了。

然后呢，庫(kù)存服務(wù)直接提供的那個(gè) reduceStock() 接口里，也別直接扣減庫(kù)存啊，你可以是凍結(jié)掉庫(kù)存。

舉個(gè)例子，本來(lái)你的庫(kù)存數(shù)量是 100，你別直接 100 - 2 = 98，扣減這個(gè)庫(kù)存！

你可以把可銷售的庫(kù)存：100 - 2 = 98，設(shè)置為 98 沒(méi)問(wèn)題，然后在一個(gè)單獨(dú)的凍結(jié)庫(kù)存的字段里，設(shè)置一個(gè) 2。也就是說(shuō)，有 2 個(gè)庫(kù)存是給凍結(jié)了。

積分服務(wù)的 addCredit() 接口也是同理，別直接給用戶增加會(huì)員積分。你可以先在積分表里的一個(gè)預(yù)增加積分字段加入積分。

比如：用戶積分原本是 1190，現(xiàn)在要增加 10 個(gè)積分，別直接 1190 + 10 = 1200 個(gè)積分啊！

你可以保持積分為 1190 不變，在一個(gè)預(yù)增加字段里，比如說(shuō) prepare_add_credit 字段，設(shè)置一個(gè) 10，表示有 10 個(gè)積分準(zhǔn)備增加。

倉(cāng)儲(chǔ)服務(wù)的 saleDelivery() 接口也是同理啊，你可以先創(chuàng)建一個(gè)銷售出庫(kù)單，但是這個(gè)銷售出庫(kù)單的狀態(tài)是“UNKNOWN”。

也就是說(shuō)，剛剛創(chuàng)建這個(gè)銷售出庫(kù)單，此時(shí)還不確定它的狀態(tài)是什么呢！

上面這套改造接口的過(guò)程，其實(shí)就是所謂的 TCC 分布式事務(wù)中的第一個(gè) T 字母代表的階段，也就是 Try 階段。

總結(jié)上述過(guò)程，如果你要實(shí)現(xiàn)一個(gè) TCC 分布式事務(wù)，首先你的業(yè)務(wù)的主流程以及各個(gè)接口提供的業(yè)務(wù)含義，不是說(shuō)直接完成那個(gè)業(yè)務(wù)操作，而是完成一個(gè) Try 的操作。

這個(gè)操作，一般都是鎖定某個(gè)資源，設(shè)置一個(gè)預(yù)備類的狀態(tài)，凍結(jié)部分?jǐn)?shù)據(jù)，等等，大概都是這類操作。

咱們來(lái)一起看看下面這張圖，結(jié)合上面的文字，再來(lái)捋一捋整個(gè)過(guò)程：

TCC 實(shí)現(xiàn)階段二：Confirm

然后就分成兩種情況了，第一種情況是比較理想的，那就是各個(gè)服務(wù)執(zhí)行自己的那個(gè) Try 操作，都執(zhí)行成功了，Bingo！

這個(gè)時(shí)候，就需要依靠 TCC 分布式事務(wù)框架來(lái)推動(dòng)后續(xù)的執(zhí)行了。這里簡(jiǎn)單提一句，如果你要玩兒 TCC 分布式事務(wù)，必須引入一款 TCC 分布式事務(wù)框架，比如國(guó)內(nèi)開源的 ByteTCC、Himly、TCC-transaction。

否則的話，感知各個(gè)階段的執(zhí)行情況以及推進(jìn)執(zhí)行下一個(gè)階段的這些事情，不太可能自己手寫實(shí)現(xiàn)，太復(fù)雜了。

如果你在各個(gè)服務(wù)里引入了一個(gè) TCC 分布式事務(wù)的框架，訂單服務(wù)里內(nèi)嵌的那個(gè) TCC 分布式事務(wù)框架可以感知到，各個(gè)服務(wù)的 Try 操作都成功了。

此時(shí)，TCC 分布式事務(wù)框架會(huì)控制進(jìn)入 TCC 下一個(gè)階段，第一個(gè) C 階段，也就是 Confirm 階段。

為了實(shí)現(xiàn)這個(gè)階段，你需要在各個(gè)服務(wù)里再加入一些代碼。比如說(shuō)，訂單服務(wù)里，你可以加入一個(gè) Confirm 的邏輯，就是正式把訂單的狀態(tài)設(shè)置為“已支付”了，大概是類似下面這樣子：

public class OrderServiceConfirm {

    public void pay(){
        orderDao.updateStatus(OrderStatus.PAYED);
    }
}

庫(kù)存服務(wù)也是類似的，你可以有一個(gè) InventoryServiceConfirm 類，里面提供一個(gè) reduceStock() 接口的 Confirm 邏輯，這里就是將之前凍結(jié)庫(kù)存字段的 2 個(gè)庫(kù)存扣掉變?yōu)?0。

這樣的話，可銷售庫(kù)存之前就已經(jīng)變?yōu)?98 了，現(xiàn)在凍結(jié)的 2 個(gè)庫(kù)存也沒(méi)了，那就正式完成了庫(kù)存的扣減。

積分服務(wù)也是類似的，可以在積分服務(wù)里提供一個(gè) CreditServiceConfirm 類，里面有一個(gè) addCredit() 接口的 Confirm 邏輯，就是將預(yù)增加字段的 10 個(gè)積分扣掉，然后加入實(shí)際的會(huì)員積分字段中，從 1190 變?yōu)?1120。

倉(cāng)儲(chǔ)服務(wù)也是類似，可以在倉(cāng)儲(chǔ)服務(wù)中提供一個(gè) WmsServiceConfirm 類，提供一個(gè) saleDelivery() 接口的 Confirm 邏輯，將銷售出庫(kù)單的狀態(tài)正式修改為“已創(chuàng)建”，可以供倉(cāng)儲(chǔ)管理人員查看和使用，而不是停留在之前的中間狀態(tài)“UNKNOWN”了。

好了，上面各種服務(wù)的 Confirm 的邏輯都實(shí)現(xiàn)好了，一旦訂單服務(wù)里面的 TCC 分布式事務(wù)框架感知到各個(gè)服務(wù)的 Try 階段都成功了以后，就會(huì)執(zhí)行各個(gè)服務(wù)的 Confirm 邏輯。

訂單服務(wù)內(nèi)的 TCC 事務(wù)框架會(huì)負(fù)責(zé)跟其他各個(gè)服務(wù)內(nèi)的 TCC 事務(wù)框架進(jìn)行通信，依次調(diào)用各個(gè)服務(wù)的 Confirm 邏輯。然后，正式完成各個(gè)服務(wù)的所有業(yè)務(wù)邏輯的執(zhí)行。

同樣，給大家來(lái)一張圖，順著圖一起來(lái)看看整個(gè)過(guò)程：

TCC 實(shí)現(xiàn)階段三：Cancel

好，這是比較正常的一種情況，那如果是異常的一種情況呢？

舉個(gè)例子：在 Try 階段，比如積分服務(wù)吧，它執(zhí)行出錯(cuò)了，此時(shí)會(huì)怎么樣？

那訂單服務(wù)內(nèi)的 TCC 事務(wù)框架是可以感知到的，然后它會(huì)決定對(duì)整個(gè) TCC 分布式事務(wù)進(jìn)行回滾。

也就是說(shuō)，會(huì)執(zhí)行各個(gè)服務(wù)的第二個(gè) C 階段，Cancel 階段。同樣，為了實(shí)現(xiàn)這個(gè) Cancel 階段，各個(gè)服務(wù)還得加一些代碼。

首先訂單服務(wù)，它得提供一個(gè) OrderServiceCancel 的類，在里面有一個(gè) pay() 接口的 Cancel 邏輯，就是可以將訂單的狀態(tài)設(shè)置為“CANCELED”，也就是這個(gè)訂單的狀態(tài)是已取消。

庫(kù)存服務(wù)也是同理，可以提供 reduceStock() 的 Cancel 邏輯，就是將凍結(jié)庫(kù)存扣減掉 2，加回到可銷售庫(kù)存里去，98 + 2 = 100。

積分服務(wù)也需要提供 addCredit() 接口的 Cancel 邏輯，將預(yù)增加積分字段的 10 個(gè)積分扣減掉。

倉(cāng)儲(chǔ)服務(wù)也需要提供一個(gè) saleDelivery() 接口的 Cancel 邏輯，將銷售出庫(kù)單的狀態(tài)修改為“CANCELED”設(shè)置為已取消。

然后這個(gè)時(shí)候，訂單服務(wù)的 TCC 分布式事務(wù)框架只要感知到了任何一個(gè)服務(wù)的 Try 邏輯失敗了，就會(huì)跟各個(gè)服務(wù)內(nèi)的 TCC 分布式事務(wù)框架進(jìn)行通信，然后調(diào)用各個(gè)服務(wù)的 Cancel 邏輯。

大家看看下面的圖，直觀的感受一下：

總結(jié)與思考

好了，兄弟們，聊到這兒，基本上大家應(yīng)該都知道 TCC 分布式事務(wù)具體是怎么回事了！

總結(jié)一下，你要玩兒 TCC 分布式事務(wù)的話：首先需要選擇某種 TCC 分布式事務(wù)框架，各個(gè)服務(wù)里就會(huì)有這個(gè) TCC 分布式事務(wù)框架在運(yùn)行。

然后你原本的一個(gè)接口，要改造為 3 個(gè)邏輯，Try-Confirm-Cancel：

• 先是服務(wù)調(diào)用鏈路依次執(zhí)行 Try 邏輯。

• 如果都正常的話，TCC 分布式事務(wù)框架推進(jìn)執(zhí)行 Confirm 邏輯，完成整個(gè)事務(wù)。

• 如果某個(gè)服務(wù)的 Try 邏輯有問(wèn)題，TCC 分布式事務(wù)框架感知到之后就會(huì)推進(jìn)執(zhí)行各個(gè)服務(wù)的 Cancel 邏輯，撤銷之前執(zhí)行的各種操作。

這就是所謂的 TCC 分布式事務(wù)。TCC 分布式事務(wù)的核心思想，說(shuō)白了，就是當(dāng)遇到下面這些情況時(shí)：

• 某個(gè)服務(wù)的數(shù)據(jù)庫(kù)宕機(jī)了。

• 某個(gè)服務(wù)自己掛了。

• 那個(gè)服務(wù)的 Redis、Elasticsearch、MQ 等基礎(chǔ)設(shè)施故障了。

• 某些資源不足了，比如說(shuō)庫(kù)存不夠這些。

先來(lái) Try 一下，不要把業(yè)務(wù)邏輯完成，先試試看，看各個(gè)服務(wù)能不能基本正常運(yùn)轉(zhuǎn)，能不能先凍結(jié)我需要的資源。

如果 Try 都 OK，也就是說(shuō)，底層的數(shù)據(jù)庫(kù)、Redis、Elasticsearch、MQ 都是可以寫入數(shù)據(jù)的，并且你保留好了需要使用的一些資源（比如凍結(jié)了一部分庫(kù)存）。

接著，再執(zhí)行各個(gè)服務(wù)的 Confirm 邏輯，基本上 Confirm 就可以很大概率保證一個(gè)分布式事務(wù)的完成了。

那如果 Try 階段某個(gè)服務(wù)就失敗了，比如說(shuō)底層的數(shù)據(jù)庫(kù)掛了，或者 Redis 掛了，等等。

此時(shí)就自動(dòng)執(zhí)行各個(gè)服務(wù)的 Cancel 邏輯，把之前的 Try 邏輯都回滾，所有服務(wù)都不要執(zhí)行任何設(shè)計(jì)的業(yè)務(wù)邏輯。保證大家要么一起成功，要么一起失敗。

等一等，你有沒(méi)有想到一個(gè)問(wèn)題？如果有一些意外的情況發(fā)生了，比如說(shuō)訂單服務(wù)突然掛了，然后再次重啟，TCC 分布式事務(wù)框架是如何保證之前沒(méi)執(zhí)行完的分布式事務(wù)繼續(xù)執(zhí)行的呢？

所以，TCC 事務(wù)框架都是要記錄一些分布式事務(wù)的活動(dòng)日志的，可以在磁盤上的日志文件里記錄，也可以在數(shù)據(jù)庫(kù)里記錄。保存下來(lái)分布式事務(wù)運(yùn)行的各個(gè)階段和狀態(tài)。

問(wèn)題還沒(méi)完，萬(wàn)一某個(gè)服務(wù)的 Cancel 或者 Confirm 邏輯執(zhí)行一直失敗怎么辦呢？

那也很簡(jiǎn)單，TCC 事務(wù)框架會(huì)通過(guò)活動(dòng)日志記錄各個(gè)服務(wù)的狀態(tài)。舉個(gè)例子，比如發(fā)現(xiàn)某個(gè)服務(wù)的 Cancel 或者 Confirm 一直沒(méi)成功，會(huì)不停的重試調(diào)用它的 Cancel 或者 Confirm 邏輯，務(wù)必要它成功！

當(dāng)然了，如果你的代碼沒(méi)有寫什么 Bug，有充足的測(cè)試，而且 Try 階段都基本嘗試了一下，那么其實(shí)一般 Confirm、Cancel 都是可以成功的！

最后，再給大家來(lái)一張圖，來(lái)看看給我們的業(yè)務(wù)，加上分布式事務(wù)之后的整個(gè)執(zhí)行流程：

不少大公司里，其實(shí)都是自己研發(fā) TCC 分布式事務(wù)框架的，專門在公司內(nèi)部使用，比如我們就是這樣。

不過(guò)如果自己公司沒(méi)有研發(fā) TCC 分布式事務(wù)框架的話，那一般就會(huì)選用開源的框架。

這里筆者給大家推薦幾個(gè)比較不錯(cuò)的框架，都是咱們國(guó)內(nèi)自己開源出去的：ByteTCC，TCC-transaction，Himly。

大家有興趣的可以去它們的 GitHub 地址，學(xué)習(xí)一下如何使用，以及如何跟 Spring Cloud、Dubbo 等服務(wù)框架整合使用。

只要把那些框架整合到你的系統(tǒng)里，很容易就可以實(shí)現(xiàn)上面那種奇妙的 TCC 分布式事務(wù)的效果了。

下面，我們來(lái)講講可靠消息最終一致性方案實(shí)現(xiàn)的分布式事務(wù)，同時(shí)聊聊在實(shí)際生產(chǎn)中遇到的運(yùn)用該方案的高可用保障架構(gòu)。

最終一致性分布式事務(wù)如何保障實(shí)際生產(chǎn)中 99.99% 高可用

上面咱們聊了聊 TCC 分布式事務(wù)，對(duì)于常見的微服務(wù)系統(tǒng)，大部分接口調(diào)用是同步的，也就是一個(gè)服務(wù)直接調(diào)用另外一個(gè)服務(wù)的接口。

這個(gè)時(shí)候，用 TCC 分布式事務(wù)方案來(lái)保證各個(gè)接口的調(diào)用，要么一起成功，要么一起回滾，是比較合適的。

但是在實(shí)際系統(tǒng)的開發(fā)過(guò)程中，可能服務(wù)間的調(diào)用是異步的。也就是說(shuō)，一個(gè)服務(wù)發(fā)送一個(gè)消息給 MQ，即消息中間件，比如 RocketMQ、RabbitMQ、Kafka、ActiveMQ 等等。

然后，另外一個(gè)服務(wù)從 MQ 消費(fèi)到一條消息后進(jìn)行處理。這就成了基于 MQ 的異步調(diào)用了。

那么針對(duì)這種基于 MQ 的異步調(diào)用，如何保證各個(gè)服務(wù)間的分布式事務(wù)呢？也就是說(shuō)，我希望的是基于 MQ 實(shí)現(xiàn)異步調(diào)用的多個(gè)服務(wù)的業(yè)務(wù)邏輯，要么一起成功，要么一起失敗。

這個(gè)時(shí)候，就要用上可靠消息最終一致性方案，來(lái)實(shí)現(xiàn)分布式事務(wù)。

大家看上圖，如果不考慮各種高并發(fā)、高可用等技術(shù)挑戰(zhàn)的話，單從“可靠消息”以及“最終一致性”兩個(gè)角度來(lái)考慮，這種分布式事務(wù)方案還是比較簡(jiǎn)單的。

可靠消息最終一致性方案的核心流程

①上游服務(wù)投遞消息

如果要實(shí)現(xiàn)可靠消息最終一致性方案，一般你可以自己寫一個(gè)可靠消息服務(wù)，實(shí)現(xiàn)一些業(yè)務(wù)邏輯。

首先，上游服務(wù)需要發(fā)送一條消息給可靠消息服務(wù)。這條消息說(shuō)白了，你可以認(rèn)為是對(duì)下游服務(wù)一個(gè)接口的調(diào)用，里面包含了對(duì)應(yīng)的一些請(qǐng)求參數(shù)。

然后，可靠消息服務(wù)就得把這條消息存儲(chǔ)到自己的數(shù)據(jù)庫(kù)里去，狀態(tài)為“待確認(rèn)”。

接著，上游服務(wù)就可以執(zhí)行自己本地的數(shù)據(jù)庫(kù)操作，根據(jù)自己的執(zhí)行結(jié)果，再次調(diào)用可靠消息服務(wù)的接口。

如果本地?cái)?shù)據(jù)庫(kù)操作執(zhí)行成功了，那么就找可靠消息服務(wù)確認(rèn)那條消息。如果本地?cái)?shù)據(jù)庫(kù)操作失敗了，那么就找可靠消息服務(wù)刪除那條消息。

此時(shí)如果是確認(rèn)消息，那么可靠消息服務(wù)就把數(shù)據(jù)庫(kù)里的消息狀態(tài)更新為“已發(fā)送”，同時(shí)將消息發(fā)送給 MQ。

這里有一個(gè)很關(guān)鍵的點(diǎn)，就是更新數(shù)據(jù)庫(kù)里的消息狀態(tài)和投遞消息到 MQ。這倆操作，你得放在一個(gè)方法里，而且得開啟本地事務(wù)。

啥意思呢？如果數(shù)據(jù)庫(kù)里更新消息的狀態(tài)失敗了，那么就拋異常退出了，就別投遞到 MQ；如果投遞 MQ 失敗報(bào)錯(cuò)了，那么就要拋異常讓本地?cái)?shù)據(jù)庫(kù)事務(wù)回滾。這倆操作必須得一起成功，或者一起失敗。

如果上游服務(wù)是通知?jiǎng)h除消息，那么可靠消息服務(wù)就得刪除這條消息。

②下游服務(wù)接收消息

下游服務(wù)就一直等著從 MQ 消費(fèi)消息好了，如果消費(fèi)到了消息，那么就操作自己本地?cái)?shù)據(jù)庫(kù)。

如果操作成功了，就反過(guò)來(lái)通知可靠消息服務(wù)，說(shuō)自己處理成功了，然后可靠消息服務(wù)就會(huì)把消息的狀態(tài)設(shè)置為“已完成”。

③如何保證上游服務(wù)對(duì)消息的 100% 可靠投遞？

上面的核心流程大家都看完：一個(gè)很大的問(wèn)題就是，如果在上述投遞消息的過(guò)程中各個(gè)環(huán)節(jié)出現(xiàn)了問(wèn)題該怎么辦？

我們?nèi)绾伪ＷC消息 100% 的可靠投遞，一定會(huì)從上游服務(wù)投遞到下游服務(wù)？別著急，下面我們來(lái)逐一分析。

如果上游服務(wù)給可靠消息服務(wù)發(fā)送待確認(rèn)消息的過(guò)程出錯(cuò)了，那沒(méi)關(guān)系，上游服務(wù)可以感知到調(diào)用異常的，就不用執(zhí)行下面的流程了，這是沒(méi)問(wèn)題的。

如果上游服務(wù)操作完本地?cái)?shù)據(jù)庫(kù)之后，通知可靠消息服務(wù)確認(rèn)消息或者刪除消息的時(shí)候，出現(xiàn)了問(wèn)題。

比如：沒(méi)通知成功，或者沒(méi)執(zhí)行成功，或者是可靠消息服務(wù)沒(méi)成功的投遞消息到 MQ。這一系列步驟出了問(wèn)題怎么辦？

其實(shí)也沒(méi)關(guān)系，因?yàn)樵谶@些情況下，那條消息在可靠消息服務(wù)的數(shù)據(jù)庫(kù)里的狀態(tài)會(huì)一直是“待確認(rèn)”。

此時(shí)，我們?cè)诳煽肯⒎?wù)里開發(fā)一個(gè)后臺(tái)定時(shí)運(yùn)行的線程，不停的檢查各個(gè)消息的狀態(tài)。

如果一直是“待確認(rèn)”狀態(tài)，就認(rèn)為這個(gè)消息出了點(diǎn)什么問(wèn)題。此時(shí)的話，就可以回調(diào)上游服務(wù)提供的一個(gè)接口，問(wèn)問(wèn)說(shuō)，兄弟，這個(gè)消息對(duì)應(yīng)的數(shù)據(jù)庫(kù)操作，你執(zhí)行成功了沒(méi)??？

如果上游服務(wù)答復(fù)說(shuō)，我執(zhí)行成功了，那么可靠消息服務(wù)將消息狀態(tài)修改為“已發(fā)送”，同時(shí)投遞消息到 MQ。

如果上游服務(wù)答復(fù)說(shuō)，沒(méi)執(zhí)行成功，那么可靠消息服務(wù)將數(shù)據(jù)庫(kù)中的消息刪除即可。

通過(guò)這套機(jī)制，就可以保證，可靠消息服務(wù)一定會(huì)嘗試完成消息到 MQ 的投遞。

④如何保證下游服務(wù)對(duì)消息的 100% 可靠接收？

那如果下游服務(wù)消費(fèi)消息出了問(wèn)題，沒(méi)消費(fèi)到？或者是下游服務(wù)對(duì)消息的處理失敗了，怎么辦？

其實(shí)也沒(méi)關(guān)系，在可靠消息服務(wù)里開發(fā)一個(gè)后臺(tái)線程，不斷的檢查消息狀態(tài)。

如果消息狀態(tài)一直是“已發(fā)送”，始終沒(méi)有變成“已完成”，那么就說(shuō)明下游服務(wù)始終沒(méi)有處理成功。

此時(shí)可靠消息服務(wù)就可以再次嘗試重新投遞消息到 MQ，讓下游服務(wù)來(lái)再次處理。

只要下游服務(wù)的接口邏輯實(shí)現(xiàn)冪等性，保證多次處理一個(gè)消息，不會(huì)插入重復(fù)數(shù)據(jù)即可。

⑤如何基于 RocketMQ 來(lái)實(shí)現(xiàn)可靠消息最終一致性方案？

在上面的通用方案設(shè)計(jì)里，完全依賴可靠消息服務(wù)的各種自檢機(jī)制來(lái)確保：

• 如果上游服務(wù)的數(shù)據(jù)庫(kù)操作沒(méi)成功，下游服務(wù)是不會(huì)收到任何通知。

• 如果上游服務(wù)的數(shù)據(jù)庫(kù)操作成功了，可靠消息服務(wù)死活都會(huì)確保將一個(gè)調(diào)用消息投遞給下游服務(wù)，而且一定會(huì)確保下游服務(wù)務(wù)必成功處理這條消息。

通過(guò)這套機(jī)制，保證了基于 MQ 的異步調(diào)用/通知的服務(wù)間的分布式事務(wù)保障。其實(shí)阿里開源的 RocketMQ，就實(shí)現(xiàn)了可靠消息服務(wù)的所有功能，核心思想跟上面類似。

只不過(guò) RocketMQ 為了保證高并發(fā)、高可用、高性能，做了較為復(fù)雜的架構(gòu)實(shí)現(xiàn)，非常的優(yōu)秀。有興趣的同學(xué)，自己可以去查閱 RocketMQ 對(duì)分布式事務(wù)的支持。

可靠消息最終一致性方案的高可用保障生產(chǎn)實(shí)踐

背景引入

上面那套方案和思想，很多同學(xué)應(yīng)該都知道是怎么回事兒，我們也主要就是鋪墊一下這套理論思想。

在實(shí)際落地生產(chǎn)的時(shí)候，如果沒(méi)有高并發(fā)場(chǎng)景的，完全可以參照上面的思路自己基于某個(gè) MQ 中間件開發(fā)一個(gè)可靠消息服務(wù)。

如果有高并發(fā)場(chǎng)景的，可以用 RocketMQ 的分布式事務(wù)支持上面的那套流程都可以實(shí)現(xiàn)。

今天給大家分享的一個(gè)核心主題，就是這套方案如何保證 99.99% 的高可用。

大家應(yīng)該發(fā)現(xiàn)了這套方案里保障高可用性最大的一個(gè)依賴點(diǎn)，就是 MQ 的高可用性。

任何一種 MQ 中間件都有一整套的高可用保障機(jī)制，無(wú)論是 RabbitMQ、RocketMQ 還是 Kafka。

所以在大公司里使用可靠消息最終一致性方案的時(shí)候，我們通常對(duì)可用性的保障都是依賴于公司基礎(chǔ)架構(gòu)團(tuán)隊(duì)對(duì) MQ 的高可用保障。

也就是說(shuō)，大家應(yīng)該相信兄弟團(tuán)隊(duì)，99.99% 可以保障 MQ 的高可用，絕對(duì)不會(huì)因?yàn)?MQ 集群整體宕機(jī)，而導(dǎo)致公司業(yè)務(wù)系統(tǒng)的分布式事務(wù)全部無(wú)法運(yùn)行。

但是現(xiàn)實(shí)是很殘酷的，很多中小型的公司，甚至是一些中大型公司，或多或少都遇到過(guò) MQ 集群整體故障的場(chǎng)景。

MQ 一旦完全不可用，就會(huì)導(dǎo)致業(yè)務(wù)系統(tǒng)的各個(gè)服務(wù)之間無(wú)法通過(guò) MQ 來(lái)投遞消息，導(dǎo)致業(yè)務(wù)流程中斷。

比如最近就有一個(gè)朋友的公司，也是做電商業(yè)務(wù)的，就遇到了 MQ 中間件在自己公司機(jī)器上部署的集群整體故障不可用，導(dǎo)致依賴 MQ 的分布式事務(wù)全部無(wú)法跑通，業(yè)務(wù)流程大量中斷的情況。

這種情況，就需要針對(duì)這套分布式事務(wù)方案實(shí)現(xiàn)一套高可用保障機(jī)制。

基于 KV 存儲(chǔ)的隊(duì)列支持的高可用降級(jí)方案

大家來(lái)看看下面這張圖，這是我曾經(jīng)指導(dǎo)過(guò)朋友的一個(gè)公司針對(duì)可靠消息最終一致性方案設(shè)計(jì)的一套高可用保障降級(jí)機(jī)制。

這套機(jī)制不算太復(fù)雜，可以非常簡(jiǎn)單有效的保證那位朋友公司的高可用保障場(chǎng)景，一旦 MQ 中間件出現(xiàn)故障，立馬自動(dòng)降級(jí)為備用方案。

①自行封裝 MQ 客戶端組件與故障感知

首先第一點(diǎn)，你要做到自動(dòng)感知 MQ 的故障接著自動(dòng)完成降級(jí)，那么必須動(dòng)手對(duì) MQ 客戶端進(jìn)行封裝，發(fā)布到公司 Nexus 私服上去。

然后公司需要支持 MQ 降級(jí)的業(yè)務(wù)服務(wù)都使用這個(gè)自己封裝的組件來(lái)發(fā)送消息到 MQ，以及從 MQ 消費(fèi)消息。

在你自己封裝的 MQ 客戶端組件里，你可以根據(jù)寫入 MQ 的情況來(lái)判斷 MQ 是否故障。

比如說(shuō)，如果連續(xù) 10 次重新嘗試投遞消息到 MQ 都發(fā)現(xiàn)異常報(bào)錯(cuò)，網(wǎng)絡(luò)無(wú)法聯(lián)通等問(wèn)題，說(shuō)明 MQ 故障，此時(shí)就可以自動(dòng)感知以及自動(dòng)觸發(fā)降級(jí)開關(guān)。

②基于 KV 存儲(chǔ)中隊(duì)列的降級(jí)方案

如果 MQ 掛掉之后，要是希望繼續(xù)投遞消息，那么就必須得找一個(gè) MQ 的替代品。

舉個(gè)例子，比如我那位朋友的公司是沒(méi)有高并發(fā)場(chǎng)景的，消息的量很少，只不過(guò)可用性要求高。此時(shí)就可以使用類似 Redis 的 KV 存儲(chǔ)中的隊(duì)列來(lái)進(jìn)行替代。

由于 Redis 本身就支持隊(duì)列的功能，還有類似隊(duì)列的各種數(shù)據(jù)結(jié)構(gòu)，所以你可以將消息寫入 KV 存儲(chǔ)格式的隊(duì)列數(shù)據(jù)結(jié)構(gòu)中去。

PS：關(guān)于 Redis 的數(shù)據(jù)存儲(chǔ)格式、支持的數(shù)據(jù)結(jié)構(gòu)等基礎(chǔ)知識(shí)，請(qǐng)大家自行查閱了，網(wǎng)上一大堆。

但是，這里有幾個(gè)大坑，一定要注意一下：

第一個(gè)，任何 KV 存儲(chǔ)的集合類數(shù)據(jù)結(jié)構(gòu)，建議不要往里面寫入數(shù)據(jù)量過(guò)大，否則會(huì)導(dǎo)致大 Value 的情況發(fā)生，引發(fā)嚴(yán)重的后果。

因此絕不能在 Redis 里搞一個(gè) Key，就拼命往這個(gè)數(shù)據(jù)結(jié)構(gòu)中一直寫入消息，這是肯定不行的。

第二個(gè)，絕對(duì)不能往少數(shù) Key 對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)中持續(xù)寫入數(shù)據(jù)，那樣會(huì)導(dǎo)致熱 Key 的產(chǎn)生，也就是某幾個(gè) Key 特別熱。

大家要知道，一般 KV 集群，都是根據(jù) Key 來(lái) Hash 分配到各個(gè)機(jī)器上的，你要是老寫少數(shù)幾個(gè) Key，會(huì)導(dǎo)致 KV 集群中的某臺(tái)機(jī)器訪問(wèn)過(guò)高，負(fù)載過(guò)大。

基于以上考慮，下面是筆者當(dāng)時(shí)設(shè)計(jì)的方案：

根據(jù)它們每天的消息量，在 KV 存儲(chǔ)中固定劃分上百個(gè)隊(duì)列，有上百個(gè) Key 對(duì)應(yīng)。這樣保證每個(gè) Key 對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)中不會(huì)寫入過(guò)多的消息，而且不會(huì)頻繁的寫少數(shù)幾個(gè) Key。一旦發(fā)生了 MQ 故障，可靠消息服務(wù)可以對(duì)每個(gè)消息通過(guò) Hash 算法，均勻的寫入固定好的上百個(gè) Key 對(duì)應(yīng)的 KV 存儲(chǔ)的隊(duì)列中。

同時(shí)需要通過(guò) ZK 觸發(fā)一個(gè)降級(jí)開關(guān)，整個(gè)系統(tǒng)在 MQ 這塊的讀和寫全部立馬降級(jí)。

③下游服務(wù)消費(fèi) MQ 的降級(jí)感知

下游服務(wù)消費(fèi) MQ 也是通過(guò)自行封裝的組件來(lái)做的，此時(shí)那個(gè)組件如果從 ZK 感知到降級(jí)開關(guān)打開了，首先會(huì)判斷自己是否還能繼續(xù)從 MQ 消費(fèi)到數(shù)據(jù)？

如果不能了，就開啟多個(gè)線程，并發(fā)的從 KV 存儲(chǔ)的各個(gè)預(yù)設(shè)好的上百個(gè)隊(duì)列中不斷的獲取數(shù)據(jù)。

每次獲取到一條數(shù)據(jù)，就交給下游服務(wù)的業(yè)務(wù)邏輯來(lái)執(zhí)行。通過(guò)這套機(jī)制，就實(shí)現(xiàn)了 MQ 故障時(shí)候的自動(dòng)故障感知，以及自動(dòng)降級(jí)。如果系統(tǒng)的負(fù)載和并發(fā)不是很高的話，用這套方案大致是沒(méi)問(wèn)題的。

因?yàn)樵谏a(chǎn)落地的過(guò)程中，包括大量的容災(zāi)演練以及生產(chǎn)實(shí)際故障發(fā)生時(shí)的表現(xiàn)來(lái)看，都是可以有效的保證 MQ 故障時(shí)，業(yè)務(wù)流程繼續(xù)自動(dòng)運(yùn)行的。

④故障的自動(dòng)恢復(fù)

如果降級(jí)開關(guān)打開之后，自行封裝的組件需要開啟一個(gè)線程，每隔一段時(shí)間嘗試給 MQ 投遞一個(gè)消息看看是否恢復(fù)了。

如果 MQ 已經(jīng)恢復(fù)可以正常投遞消息了，此時(shí)就可以通過(guò) ZK 關(guān)閉降級(jí)開關(guān)，然后可靠消息服務(wù)繼續(xù)投遞消息到 MQ，下游服務(wù)在確認(rèn) KV 存儲(chǔ)的各個(gè)隊(duì)列中已經(jīng)沒(méi)有數(shù)據(jù)之后，就可以重新切換為從 MQ 消費(fèi)消息。

⑤更多的業(yè)務(wù)細(xì)節(jié)

上面說(shuō)的那套方案是一套通用的降級(jí)方案，但是具體的落地是要結(jié)合各個(gè)公司不同的業(yè)務(wù)細(xì)節(jié)來(lái)決定的，很多細(xì)節(jié)多沒(méi)法在文章里體現(xiàn)。

比如說(shuō)你們要不要保證消息的順序性？是不是涉及到需要根據(jù)業(yè)務(wù)動(dòng)態(tài)，生成大量的 Key？等等。

此外，這套方案實(shí)現(xiàn)起來(lái)還是有一定的成本的，所以建議大家盡可能還是 Push 公司的基礎(chǔ)架構(gòu)團(tuán)隊(duì)，保證 MQ 的 99.99% 可用性，不要宕機(jī)。

其次就是根據(jù)大家公司實(shí)際對(duì)高可用的需求來(lái)決定，如果感覺(jué) MQ 偶爾宕機(jī)也沒(méi)事，可以容忍的話，那么也不用實(shí)現(xiàn)這種降級(jí)方案。

但是如果公司領(lǐng)導(dǎo)認(rèn)為 MQ 中間件宕機(jī)后，一定要保證業(yè)務(wù)系統(tǒng)流程繼續(xù)運(yùn)行，那么還是要考慮一些高可用的降級(jí)方案，比如本文提到的這種。

最后再說(shuō)一句，真要是一些公司涉及到每秒幾萬(wàn)幾十萬(wàn)的高并發(fā)請(qǐng)求，那么對(duì) MQ 的降級(jí)方案會(huì)設(shè)計(jì)的更加的復(fù)雜，那就遠(yuǎn)遠(yuǎn)不是這么簡(jiǎn)單可以做到的。

感謝各位的閱讀！關(guān)于“Java中TCC分布式事務(wù)的實(shí)現(xiàn)原理”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！