[終于有人把“TCC分布式事務(wù)”實(shí)現(xiàn)原理講明白了俭嘁！]
之前網(wǎng)上看到很多寫分布式事務(wù)的文章，不過大多都是將分布式事務(wù)各種技術(shù)方案簡單介紹一下篮奄。很多朋友看了還是不知道分布式事務(wù)到底怎么回事霹肝，在項(xiàng)目里到底如何使用。
所以這篇文章次绘，就用大白話+手工繪圖，并結(jié)合一個(gè)電商系統(tǒng)的案例實(shí)踐撒遣，來給大家講清楚到底什么是 TCC 分布式事務(wù)邮偎。
首先說一下，這里可能會(huì)牽扯到一些 Spring Cloud 的原理义黎，如果有不太清楚的同學(xué)禾进，可以參考之前的文章：《拜托，面試請(qǐng)不要再問我Spring Cloud底層原理廉涕！》泻云。
業(yè)務(wù)場(chǎng)景介紹
咱們先來看看業(yè)務(wù)場(chǎng)景，假設(shè)你現(xiàn)在有一個(gè)電商系統(tǒng)火的，里面有一個(gè)支付訂單的場(chǎng)景壶愤。
那對(duì)一個(gè)訂單支付之后淑倾，我們需要做下面的步驟：
- 更改訂單的狀態(tài)為“已支付”
- 扣減商品庫存
- 給會(huì)員增加積分
- 創(chuàng)建銷售出庫單通知倉庫發(fā)貨
這是一系列比較真實(shí)的步驟馏鹤，無論大家有沒有做過電商系統(tǒng)，應(yīng)該都能理解娇哆。
進(jìn)一步思考
好湃累，業(yè)務(wù)場(chǎng)景有了，現(xiàn)在我們要更進(jìn)一步碍讨，實(shí)現(xiàn)一個(gè) TCC 分布式事務(wù)的效果治力。
什么意思呢？也就是說勃黍，[1] 訂單服務(wù)-修改訂單狀態(tài)宵统，[2] 庫存服務(wù)-扣減庫存，[3] 積分服務(wù)-增加積分覆获，[4] 倉儲(chǔ)服務(wù)-創(chuàng)建銷售出庫單马澈。
上述這幾個(gè)步驟瓢省，要么一起成功，要么一起失敗痊班，必須是一個(gè)整體性的事務(wù)勤婚。
舉個(gè)例子，現(xiàn)在訂單的狀態(tài)都修改為“已支付”了涤伐，結(jié)果庫存服務(wù)扣減庫存失敗馒胆。那個(gè)商品的庫存原來是 100 件，現(xiàn)在賣掉了 2 件凝果，本來應(yīng)該是 98 件了祝迂。
結(jié)果呢？由于庫存服務(wù)操作數(shù)據(jù)庫異常豆村，導(dǎo)致庫存數(shù)量還是 100液兽。這不是在坑人么，當(dāng)然不能允許這種情況發(fā)生了掌动！
但是如果你不用 TCC 分布式事務(wù)方案的話四啰，就用個(gè) Spring Cloud 開發(fā)這么一個(gè)微服務(wù)系統(tǒng)，很有可能會(huì)干出這種事兒來粗恢。
我們來看看下面的這個(gè)圖柑晒，直觀的表達(dá)了上述的過程：
所以說，我們有必要使用 TCC 分布式事務(wù)機(jī)制來保證各個(gè)服務(wù)形成一個(gè)整體性的事務(wù)眷射。
上面那幾個(gè)步驟匙赞，要么全部成功，如果任何一個(gè)服務(wù)的操作失敗了妖碉，就全部一起回滾涌庭，撤銷已經(jīng)完成的操作。
比如說庫存服務(wù)要是扣減庫存失敗了欧宜，那么訂單服務(wù)就得撤銷那個(gè)修改訂單狀態(tài)的操作坐榆，然后得停止執(zhí)行增加積分和通知出庫兩個(gè)操作。
說了那么多冗茸，老規(guī)矩席镀，給大家上一張圖，大伙兒順著圖來直觀的感受一下：
落地實(shí)現(xiàn) TCC 分布式事務(wù)
那么現(xiàn)在到底要如何來實(shí)現(xiàn)一個(gè) TCC 分布式事務(wù)夏漱，使得各個(gè)服務(wù)豪诲，要么一起成功？要么一起失敗呢挂绰？
大家稍安勿躁屎篱，我們這就來一步一步的分析一下。咱們就以一個(gè) Spring Cloud 開發(fā)系統(tǒng)作為背景來解釋。
TCC 實(shí)現(xiàn)階段一：Try
首先交播，訂單服務(wù)那兒专肪，它的代碼大致來說應(yīng)該是這樣子的：
public class OrderService {
// 庫存服務(wù)
@Autowired
private InventoryService inventoryService;
// 積分服務(wù)
@Autowired
private CreditService creditService;
// 倉儲(chǔ)服務(wù)
@Autowired
private WmsService wmsService;
// 對(duì)這個(gè)訂單完成支付
public void pay(){
//對(duì)本地的的訂單數(shù)據(jù)庫修改訂單狀態(tài)為"已支付"
orderDAO.updateStatus(OrderStatus.PAYED);
//調(diào)用庫存服務(wù)扣減庫存
inventoryService.reduceStock();
//調(diào)用積分服務(wù)增加積分
creditService.addCredit();
//調(diào)用倉儲(chǔ)服務(wù)通知發(fā)貨
wmsService.saleDelivery();
}
}
如果你之前看過 Spring Cloud 架構(gòu)原理那篇文章，同時(shí)對(duì) Spring Cloud 有一定的了解的話堪侯，應(yīng)該是可以理解上面那段代碼的嚎尤。
其實(shí)就是訂單服務(wù)完成本地?cái)?shù)據(jù)庫操作之后，通過 Spring Cloud 的 Feign 來調(diào)用其他的各個(gè)服務(wù)罷了伍宦。
但是光是憑借這段代碼芽死，是不足以實(shí)現(xiàn) TCC 分布式事務(wù)的啊次洼？关贵！兄弟們，別著急卖毁，我們對(duì)這個(gè)訂單服務(wù)修改點(diǎn)兒代碼好不好揖曾。
首先，上面那個(gè)訂單服務(wù)先把自己的狀態(tài)修改為：OrderStatus.UPDATING亥啦。
這是啥意思呢炭剪？也就是說，在 pay() 那個(gè)方法里翔脱，你別直接把訂單狀態(tài)修改為已支付芭埂！你先把訂單狀態(tài)修改為 UPDATING届吁，也就是修改中的意思错妖。
這個(gè)狀態(tài)是個(gè)沒有任何含義的這么一個(gè)狀態(tài)，代表有人正在修改這個(gè)狀態(tài)罷了疚沐。
然后呢暂氯，庫存服務(wù)直接提供的那個(gè) reduceStock() 接口里，也別直接扣減庫存啊亮蛔，你可以是凍結(jié)掉庫存痴施。
舉個(gè)例子，本來你的庫存數(shù)量是 100尔邓，你別直接 100 - 2 = 98晾剖，扣減這個(gè)庫存锉矢！
你可以把可銷售的庫存：100 - 2 = 98梯嗽，設(shè)置為 98 沒問題，然后在一個(gè)單獨(dú)的凍結(jié)庫存的字段里沽损，設(shè)置一個(gè) 2灯节。也就是說，有 2 個(gè)庫存是給凍結(jié)了。
積分服務(wù)的 addCredit() 接口也是同理炎疆，別直接給用戶增加會(huì)員積分卡骂。你可以先在積分表里的一個(gè)預(yù)增加積分字段加入積分。
比如：用戶積分原本是 1190形入，現(xiàn)在要增加 10 個(gè)積分全跨，別直接 1190 + 10 = 1200 個(gè)積分啊亿遂！
你可以保持積分為 1190 不變浓若，在一個(gè)預(yù)增加字段里，比如說 prepare_add_credit 字段蛇数，設(shè)置一個(gè) 10挪钓，表示有 10 個(gè)積分準(zhǔn)備增加。
倉儲(chǔ)服務(wù)的 saleDelivery() 接口也是同理啊耳舅，你可以先創(chuàng)建一個(gè)銷售出庫單碌上，但是這個(gè)銷售出庫單的狀態(tài)是“UNKNOWN”。
也就是說浦徊，剛剛創(chuàng)建這個(gè)銷售出庫單馏予，此時(shí)還不確定它的狀態(tài)是什么呢！
上面這套改造接口的過程盔性，其實(shí)就是所謂的 TCC 分布式事務(wù)中的第一個(gè) T 字母代表的階段吗蚌，也就是 Try 階段。
總結(jié)上述過程纯出，如果你要實(shí)現(xiàn)一個(gè) TCC 分布式事務(wù)蚯妇，首先你的業(yè)務(wù)的主流程以及各個(gè)接口提供的業(yè)務(wù)含義，不是說直接完成那個(gè)業(yè)務(wù)操作暂筝，而是完成一個(gè) Try 的操作箩言。
這個(gè)操作，一般都是鎖定某個(gè)資源焕襟，設(shè)置一個(gè)預(yù)備類的狀態(tài)陨收，凍結(jié)部分?jǐn)?shù)據(jù)，等等鸵赖，大概都是這類操作务漩。
咱們來一起看看下面這張圖，結(jié)合上面的文字它褪，再來捋一捋整個(gè)過程：
TCC 實(shí)現(xiàn)階段二：Confirm
然后就分成兩種情況了饵骨，第一種情況是比較理想的，那就是各個(gè)服務(wù)執(zhí)行自己的那個(gè) Try 操作茫打，都執(zhí)行成功了居触，Bingo妖混！
這個(gè)時(shí)候，就需要依靠 TCC 分布式事務(wù)框架來推動(dòng)后續(xù)的執(zhí)行了轮洋。這里簡單提一句制市，如果你要玩兒 TCC 分布式事務(wù)，必須引入一款 TCC 分布式事務(wù)框架弊予，比如國內(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ù)里再加入一些代碼逮壁。比如說，訂單服務(wù)里粮宛，你可以加入一個(gè) Confirm 的邏輯窥淆，就是正式把訂單的狀態(tài)設(shè)置為“已支付”了，大概是類似下面這樣子：
public class OrderServiceConfirm {
public void pay(){
orderDao.updateStatus(OrderStatus.PAYED);
}
}
庫存服務(wù)也是類似的巍杈，你可以有一個(gè) InventoryServiceConfirm 類忧饭，里面提供一個(gè) reduceStock() 接口的 Confirm 邏輯，這里就是將之前凍結(jié)庫存字段的 2 個(gè)庫存扣掉變?yōu)?0筷畦。
這樣的話词裤，可銷售庫存之前就已經(jīng)變?yōu)?98 了，現(xiàn)在凍結(jié)的 2 個(gè)庫存也沒了鳖宾，那就正式完成了庫存的扣減吼砂。
積分服務(wù)也是類似的，可以在積分服務(wù)里提供一個(gè) CreditServiceConfirm 類鼎文，里面有一個(gè) addCredit() 接口的 Confirm 邏輯渔肩，就是將預(yù)增加字段的 10 個(gè)積分扣掉，然后加入實(shí)際的會(huì)員積分字段中漂问，從 1190 變?yōu)?1120赖瞒。
倉儲(chǔ)服務(wù)也是類似，可以在倉儲(chǔ)服務(wù)中提供一個(gè) WmsServiceConfirm 類子姜，提供一個(gè) saleDelivery() 接口的 Confirm 邏輯悯森，將銷售出庫單的狀態(tài)正式修改為“已創(chuà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í)行瞒爬。
同樣弓柱，給大家來一張圖，順著圖一起來看看整個(gè)過程：
TCC 實(shí)現(xiàn)階段三：Cancel
好侧但，這是比較正常的一種情況矢空，那如果是異常的一種情況呢？
舉個(gè)例子：在 Try 階段禀横，比如積分服務(wù)吧屁药，它執(zhí)行出錯(cuò)了，此時(shí)會(huì)怎么樣柏锄？
那訂單服務(wù)內(nèi)的 TCC 事務(wù)框架是可以感知到的酿箭，然后它會(huì)決定對(duì)整個(gè) TCC 分布式事務(wù)進(jìn)行回滾。
也就是說趾娃，會(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)是已取消古程。
庫存服務(wù)也是同理，可以提供 reduceStock() 的 Cancel 邏輯喊崖，就是將凍結(jié)庫存扣減掉 2挣磨，加回到可銷售庫存里去雇逞，98 + 2 = 100。
積分服務(wù)也需要提供 addCredit() 接口的 Cancel 邏輯茁裙，將預(yù)增加積分字段的 10 個(gè)積分扣減掉塘砸。
倉儲(chǔ)服務(wù)也需要提供一個(gè) saleDelivery() 接口的 Cancel 邏輯，將銷售出庫單的狀態(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 邏輯有問題模聋，TCC 分布式事務(wù)框架感知到之后就會(huì)推進(jìn)執(zhí)行各個(gè)服務(wù)的 Cancel 邏輯，撤銷之前執(zhí)行的各種操作唠亚。
這就是所謂的 TCC 分布式事務(wù)链方。TCC 分布式事務(wù)的核心思想，說白了灶搜，就是當(dāng)遇到下面這些情況時(shí)：
- 某個(gè)服務(wù)的數(shù)據(jù)庫宕機(jī)了祟蚀。
- 某個(gè)服務(wù)自己掛了。
- 那個(gè)服務(wù)的 Redis割卖、Elasticsearch前酿、MQ 等基礎(chǔ)設(shè)施故障了。
- 某些資源不足了鹏溯，比如說庫存不夠這些罢维。
先來 Try 一下，不要把業(yè)務(wù)邏輯完成丙挽，先試試看肺孵，看各個(gè)服務(wù)能不能基本正常運(yùn)轉(zhuǎn)匀借，能不能先凍結(jié)我需要的資源。
如果 Try 都 OK平窘，也就是說吓肋，底層的數(shù)據(jù)庫、Redis初婆、Elasticsearch蓬坡、MQ 都是可以寫入數(shù)據(jù)的猿棉，并且你保留好了需要使用的一些資源（比如凍結(jié)了一部分庫存）磅叛。
接著，再執(zhí)行各個(gè)服務(wù)的 Confirm 邏輯萨赁，基本上 Confirm 就可以很大概率保證一個(gè)分布式事務(wù)的完成了弊琴。
那如果 Try 階段某個(gè)服務(wù)就失敗了，比如說底層的數(shù)據(jù)庫掛了杖爽，或者 Redis 掛了敲董，等等。
此時(shí)就自動(dòng)執(zhí)行各個(gè)服務(wù)的 Cancel 邏輯慰安，把之前的 Try 邏輯都回滾腋寨，所有服務(wù)都不要執(zhí)行任何設(shè)計(jì)的業(yè)務(wù)邏輯。保證大家要么一起成功化焕，要么一起失敗萄窜。
等一等，你有沒有想到一個(gè)問題撒桨？如果有一些意外的情況發(fā)生了查刻，比如說訂單服務(wù)突然掛了，然后再次重啟凤类，TCC 分布式事務(wù)框架是如何保證之前沒執(zhí)行完的分布式事務(wù)繼續(xù)執(zhí)行的呢穗泵？
所以，TCC 事務(wù)框架都是要記錄一些分布式事務(wù)的活動(dòng)日志的谜疤，可以在磁盤上的日志文件里記錄佃延，也可以在數(shù)據(jù)庫里記錄。保存下來分布式事務(wù)運(yùn)行的各個(gè)階段和狀態(tài)夷磕。
問題還沒完苇侵，萬一某個(gè)服務(wù)的 Cancel 或者 Confirm 邏輯執(zhí)行一直失敗怎么辦呢？
那也很簡單企锌，TCC 事務(wù)框架會(huì)通過活動(dòng)日志記錄各個(gè)服務(wù)的狀態(tài)榆浓。舉個(gè)例子，比如發(fā)現(xiàn)某個(gè)服務(wù)的 Cancel 或者 Confirm 一直沒成功撕攒，會(huì)不停的重試調(diào)用它的 Cancel 或者 Confirm 邏輯陡鹃，務(wù)必要它成功烘浦！
當(dāng)然了，如果你的代碼沒有寫什么 Bug萍鲸，有充足的測(cè)試闷叉，而且 Try 階段都基本嘗試了一下，那么其實(shí)一般 Confirm脊阴、Cancel 都是可以成功的握侧！
最后，再給大家來一張圖嘿期，來看看給我們的業(yè)務(wù)品擎，加上分布式事務(wù)之后的整個(gè)執(zhí)行流程：
不少大公司里，其實(shí)都是自己研發(fā) TCC 分布式事務(wù)框架的备徐，專門在公司內(nèi)部使用萄传，比如我們就是這樣。
不過如果自己公司沒有研發(fā) TCC 分布式事務(wù)框架的話蜜猾，那一般就會(huì)選用開源的框架秀菱。
這里筆者給大家推薦幾個(gè)比較不錯(cuò)的框架，都是咱們國內(nèi)自己開源出去的：ByteTCC蹭睡，TCC-transaction衍菱，Himly。
大家有興趣的可以去它們的 GitHub 地址肩豁，學(xué)習(xí)一下如何使用脊串，以及如何跟 Spring Cloud、Dubbo 等服務(wù)框架整合使用蓖救。
只要把那些框架整合到你的系統(tǒng)里洪规，很容易就可以實(shí)現(xiàn)上面那種奇妙的 TCC 分布式事務(wù)的效果了。
下面循捺，我們來講講可靠消息最終一致性方案實(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ù)方案來保證各個(gè)接口的調(diào)用踩萎，要么一起成功停局，要么一起回滾，是比較合適的。
但是在實(shí)際系統(tǒng)的開發(fā)過程中董栽，可能服務(wù)間的調(diào)用是異步的码倦。也就是說，一個(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ù)呢栈妆？也就是說胁编，我希望的是基于 MQ 實(shí)現(xiàn)異步調(diào)用的多個(gè)服務(wù)的業(yè)務(wù)邏輯厢钧，要么一起成功，要么一起失敗嬉橙。
這個(gè)時(shí)候早直，就要用上可靠消息最終一致性方案，來實(shí)現(xiàn)分布式事務(wù)市框。
大家看上圖霞扬，如果不考慮各種高并發(fā)、高可用等技術(shù)挑戰(zhàn)的話枫振，單從“可靠消息”以及“最終一致性”兩個(gè)角度來考慮喻圃，這種分布式事務(wù)方案還是比較簡單的。
可靠消息最終一致性方案的核心流程
①上游服務(wù)投遞消息
如果要實(shí)現(xiàn)可靠消息最終一致性方案粪滤，一般你可以自己寫一個(gè)可靠消息服務(wù)斧拍，實(shí)現(xiàn)一些業(yè)務(wù)邏輯。
首先杖小，上游服務(wù)需要發(fā)送一條消息給可靠消息服務(wù)肆汹。這條消息說白了，你可以認(rèn)為是對(duì)下游服務(wù)一個(gè)接口的調(diào)用予权，里面包含了對(duì)應(yīng)的一些請(qǐng)求參數(shù)昂勉。
然后，可靠消息服務(wù)就得把這條消息存儲(chǔ)到自己的數(shù)據(jù)庫里去扫腺，狀態(tài)為“待確認(rèn)”岗照。
接著，上游服務(wù)就可以執(zhí)行自己本地的數(shù)據(jù)庫操作，根據(jù)自己的執(zhí)行結(jié)果攒至，再次調(diào)用可靠消息服務(wù)的接口煞肾。
如果本地?cái)?shù)據(jù)庫操作執(zhí)行成功了，那么就找可靠消息服務(wù)確認(rèn)那條消息嗓袱。如果本地?cái)?shù)據(jù)庫操作失敗了籍救，那么就找可靠消息服務(wù)刪除那條消息。
此時(shí)如果是確認(rèn)消息渠抹，那么可靠消息服務(wù)就把數(shù)據(jù)庫里的消息狀態(tài)更新為“已發(fā)送”蝙昙，同時(shí)將消息發(fā)送給 MQ。
這里有一個(gè)很關(guān)鍵的點(diǎn)梧却，就是更新數(shù)據(jù)庫里的消息狀態(tài)和投遞消息到 MQ奇颠。這倆操作，你得放在一個(gè)方法里放航，而且得開啟本地事務(wù)烈拒。
啥意思呢？如果數(shù)據(jù)庫里更新消息的狀態(tài)失敗了广鳍，那么就拋異常退出了荆几，就別投遞到 MQ；如果投遞 MQ 失敗報(bào)錯(cuò)了赊时，那么就要拋異常讓本地?cái)?shù)據(jù)庫事務(wù)回滾吨铸。這倆操作必須得一起成功，或者一起失敗祖秒。
如果上游服務(wù)是通知?jiǎng)h除消息诞吱，那么可靠消息服務(wù)就得刪除這條消息。
②下游服務(wù)接收消息
下游服務(wù)就一直等著從 MQ 消費(fèi)消息好了竭缝，如果消費(fèi)到了消息房维，那么就操作自己本地?cái)?shù)據(jù)庫。
如果操作成功了抬纸，就反過來通知可靠消息服務(wù)咙俩，說自己處理成功了，然后可靠消息服務(wù)就會(huì)把消息的狀態(tài)設(shè)置為“已完成”松却。
③如何保證上游服務(wù)對(duì)消息的 100% 可靠投遞暴浦？
上面的核心流程大家都看完：一個(gè)很大的問題就是，如果在上述投遞消息的過程中各個(gè)環(huán)節(jié)出現(xiàn)了問題該怎么辦晓锻？
我們?nèi)绾伪ＷC消息 100% 的可靠投遞歌焦，一定會(huì)從上游服務(wù)投遞到下游服務(wù)？別著急砚哆，下面我們來逐一分析独撇。
如果上游服務(wù)給可靠消息服務(wù)發(fā)送待確認(rèn)消息的過程出錯(cuò)了，那沒關(guān)系，上游服務(wù)可以感知到調(diào)用異常的纷铣，就不用執(zhí)行下面的流程了卵史，這是沒問題的。
如果上游服務(wù)操作完本地?cái)?shù)據(jù)庫之后搜立，通知可靠消息服務(wù)確認(rèn)消息或者刪除消息的時(shí)候以躯，出現(xiàn)了問題。
比如：沒通知成功啄踊，或者沒執(zhí)行成功忧设，或者是可靠消息服務(wù)沒成功的投遞消息到 MQ。這一系列步驟出了問題怎么辦颠通？
其實(shí)也沒關(guān)系址晕，因?yàn)樵谶@些情況下，那條消息在可靠消息服務(wù)的數(shù)據(jù)庫里的狀態(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)什么問題。此時(shí)的話淀歇，就可以回調(diào)上游服務(wù)提供的一個(gè)接口易核，問問說匈织，兄弟浪默，這個(gè)消息對(duì)應(yīng)的數(shù)據(jù)庫操作，你執(zhí)行成功了沒白贺啊纳决？
如果上游服務(wù)答復(fù)說，我執(zhí)行成功了乡小，那么可靠消息服務(wù)將消息狀態(tài)修改為“已發(fā)送”阔加，同時(shí)投遞消息到 MQ。
如果上游服務(wù)答復(fù)說满钟，沒執(zhí)行成功胜榔，那么可靠消息服務(wù)將數(shù)據(jù)庫中的消息刪除即可。
通過這套機(jī)制湃番，就可以保證夭织，可靠消息服務(wù)一定會(huì)嘗試完成消息到 MQ 的投遞。
④如何保證下游服務(wù)對(duì)消息的 100% 可靠接收吠撮？
那如果下游服務(wù)消費(fèi)消息出了問題尊惰，沒消費(fèi)到？或者是下游服務(wù)對(duì)消息的處理失敗了，怎么辦弄屡？
其實(shí)也沒關(guān)系题禀，在可靠消息服務(wù)里開發(fā)一個(gè)后臺(tái)線程，不斷的檢查消息狀態(tài)膀捷。
如果消息狀態(tài)一直是“已發(fā)送”迈嘹，始終沒有變成“已完成”，那么就說明下游服務(wù)始終沒有處理成功全庸。
此時(shí)可靠消息服務(wù)就可以再次嘗試重新投遞消息到 MQ江锨，讓下游服務(wù)來再次處理。
只要下游服務(wù)的接口邏輯實(shí)現(xiàn)冪等性糕篇，保證多次處理一個(gè)消息啄育，不會(huì)插入重復(fù)數(shù)據(jù)即可。
⑤如何基于 RocketMQ 來實(shí)現(xiàn)可靠消息最終一致性方案拌消？
在上面的通用方案設(shè)計(jì)里挑豌，完全依賴可靠消息服務(wù)的各種自檢機(jī)制來確保：
- 如果上游服務(wù)的數(shù)據(jù)庫操作沒成功，下游服務(wù)是不會(huì)收到任何通知墩崩。
- 如果上游服務(wù)的數(shù)據(jù)庫操作成功了氓英，可靠消息服務(wù)死活都會(huì)確保將一個(gè)調(diào)用消息投遞給下游服務(wù)，而且一定會(huì)確保下游服務(wù)務(wù)必成功處理這條消息鹦筹。
通過這套機(jī)制铝阐，保證了基于 MQ 的異步調(diào)用/通知的服務(wù)間的分布式事務(wù)保障。其實(shí)阿里開源的 RocketMQ铐拐，就實(shí)現(xiàn)了可靠消息服務(wù)的所有功能徘键，核心思想跟上面類似。
只不過 RocketMQ 為了保證高并發(fā)遍蟋、高可用吹害、高性能，做了較為復(fù)雜的架構(gòu)實(shí)現(xiàn)虚青，非常的優(yōu)秀它呀。有興趣的同學(xué)，自己可以去查閱 RocketMQ 對(duì)分布式事務(wù)的支持棒厘。
可靠消息最終一致性方案的高可用保障生產(chǎn)實(shí)踐
背景引入
上面那套方案和思想纵穿，很多同學(xué)應(yīng)該都知道是怎么回事兒，我們也主要就是鋪墊一下這套理論思想奢人。
在實(shí)際落地生產(chǎn)的時(shí)候谓媒，如果沒有高并發(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ī)制蒙保，無論是 RabbitMQ辕棚、RocketMQ 還是 Kafka。
所以在大公司里使用可靠消息最終一致性方案的時(shí)候邓厕，我們通常對(duì)可用性的保障都是依賴于公司基礎(chǔ)架構(gòu)團(tuán)隊(duì)對(duì) MQ 的高可用保障逝嚎。
也就是說，大家應(yīng)該相信兄弟團(tuán)隊(duì)详恼，99.99% 可以保障 MQ 的高可用补君，絕對(duì)不會(huì)因?yàn)?MQ 集群整體宕機(jī)，而導(dǎo)致公司業(yè)務(wù)系統(tǒng)的分布式事務(wù)全部無法運(yùn)行昧互。
但是現(xiàn)實(shí)是很殘酷的挽铁，很多中小型的公司，甚至是一些中大型公司敞掘，或多或少都遇到過 MQ 集群整體故障的場(chǎng)景叽掘。
MQ 一旦完全不可用，就會(huì)導(dǎo)致業(yè)務(wù)系統(tǒng)的各個(gè)服務(wù)之間無法通過 MQ 來投遞消息玖雁，導(dǎo)致業(yè)務(wù)流程中斷更扁。
比如最近就有一個(gè)朋友的公司，也是做電商業(yè)務(wù)的赫冬，就遇到了 MQ 中間件在自己公司機(jī)器上部署的集群整體故障不可用浓镜，導(dǎo)致依賴 MQ 的分布式事務(wù)全部無法跑通，業(yè)務(wù)流程大量中斷的情況面殖。
這種情況竖哩，就需要針對(duì)這套分布式事務(wù)方案實(shí)現(xiàn)一套高可用保障機(jī)制。
基于 KV 存儲(chǔ)的隊(duì)列支持的高可用降級(jí)方案
大家來看看下面這張圖脊僚，這是我曾經(jīng)指導(dǎo)過朋友的一個(gè)公司針對(duì)可靠消息最終一致性方案設(shè)計(jì)的一套高可用保障降級(jí)機(jī)制。
這套機(jī)制不算太復(fù)雜遵绰，可以非常簡單有效的保證那位朋友公司的高可用保障場(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è)自己封裝的組件來發(fā)送消息到 MQ拳喻，以及從 MQ 消費(fèi)消息。
在你自己封裝的 MQ 客戶端組件里猪腕，你可以根據(jù)寫入 MQ 的情況來判斷 MQ 是否故障冗澈。
比如說，如果連續(xù) 10 次重新嘗試投遞消息到 MQ 都發(fā)現(xiàn)異常報(bào)錯(cuò)陋葡，網(wǎng)絡(luò)無法聯(lián)通等問題亚亲，說明 MQ 故障，此時(shí)就可以自動(dòng)感知以及自動(dòng)觸發(fā)降級(jí)開關(guān)腐缤。
②基于 KV 存儲(chǔ)中隊(duì)列的降級(jí)方案
如果 MQ 掛掉之后捌归，要是希望繼續(xù)投遞消息，那么就必須得找一個(gè) MQ 的替代品岭粤。
舉個(gè)例子惜索，比如我那位朋友的公司是沒有高并發(fā)場(chǎng)景的，消息的量很少剃浇，只不過可用性要求高门扇。此時(shí)就可以使用類似 Redis 的 KV 存儲(chǔ)中的隊(duì)列來進(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ù)量過大，否則會(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 來 Hash 分配到各個(gè)機(jī)器上的袜漩，你要是老寫少數(shù)幾個(gè) Key，會(huì)導(dǎo)致 KV 集群中的某臺(tái)機(jī)器訪問過高湾碎，負(fù)載過大宙攻。
基于以上考慮，下面是筆者當(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ì)寫入過多的消息呻顽，而且不會(huì)頻繁的寫少數(shù)幾個(gè) Key雹顺。
- 一旦發(fā)生了 MQ 故障，可靠消息服務(wù)可以對(duì)每個(gè)消息通過 Hash 算法廊遍，均勻的寫入固定好的上百個(gè) Key 對(duì)應(yīng)的 KV 存儲(chǔ)的隊(duì)列中嬉愧。
同時(shí)需要通過 ZK 觸發(fā)一個(gè)降級(jí)開關(guān)，整個(gè)系統(tǒng)在 MQ 這塊的讀和寫全部立馬降級(jí)喉前。
③下游服務(wù)消費(fèi) MQ 的降級(jí)感知
下游服務(wù)消費(fèi) MQ 也是通過自行封裝的組件來做的没酣，此時(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ù)邏輯來執(zhí)行。通過這套機(jī)制改览，就實(shí)現(xiàn)了 MQ 故障時(shí)候的自動(dòng)故障感知下翎，以及自動(dòng)降級(jí)。如果系統(tǒng)的負(fù)載和并發(fā)不是很高的話宝当，用這套方案大致是沒問題的视事。
因?yàn)樵谏a(chǎn)落地的過程中，包括大量的容災(zāi)演練以及生產(chǎn)實(shí)際故障發(fā)生時(shí)的表現(xiàn)來看庆揩，都是可以有效的保證 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í)就可以通過 ZK 關(guān)閉降級(jí)開關(guān)，然后可靠消息服務(wù)繼續(xù)投遞消息到 MQ套利，下游服務(wù)在確認(rèn) KV 存儲(chǔ)的各個(gè)隊(duì)列中已經(jīng)沒有數(shù)據(jù)之后推励，就可以重新切換為從 MQ 消費(fèi)消息鹤耍。
⑤更多的業(yè)務(wù)細(xì)節(jié)
上面說的那套方案是一套通用的降級(jí)方案，但是具體的落地是要結(jié)合各個(gè)公司不同的業(yè)務(wù)細(xì)節(jié)來決定的验辞，很多細(xì)節(jié)多沒法在文章里體現(xiàn)稿黄。
比如說你們要不要保證消息的順序性？是不是涉及到需要根據(jù)業(yè)務(wù)動(dòng)態(tài)跌造，生成大量的 Key杆怕？等等。
此外壳贪，這套方案實(shí)現(xiàn)起來還是有一定的成本的陵珍，所以建議大家盡可能還是 Push 公司的基礎(chǔ)架構(gòu)團(tuán)隊(duì)，保證 MQ 的 99.99% 可用性违施，不要宕機(jī)互纯。
其次就是根據(jù)大家公司實(shí)際對(duì)高可用的需求來決定，如果感覺 MQ 偶爾宕機(jī)也沒事磕蒲，可以容忍的話留潦，那么也不用實(shí)現(xiàn)這種降級(jí)方案。
但是如果公司領(lǐng)導(dǎo)認(rèn)為 MQ 中間件宕機(jī)后辣往，一定要保證業(yè)務(wù)系統(tǒng)流程繼續(xù)運(yùn)行兔院，那么還是要考慮一些高可用的降級(jí)方案，比如本文提到的這種站削。
最后再說一句坊萝，真要是一些公司涉及到每秒幾萬幾十萬的高并發(fā)請(qǐng)求，那么對(duì) MQ 的降級(jí)方案會(huì)設(shè)計(jì)的更加的復(fù)雜钻哩，那就遠(yuǎn)遠(yuǎn)不是這么簡單可以做到的屹堰。
