一、前言

我們小夥伴應(yīng)該都聽說(shuō)夠訊息中間件MQ，如：RabbitMQ，RocketMQ，Kafka等。引入中間件的好處可以起到抗高並發(fā)，削峰，業(yè)務(wù)解耦的作用。

如上圖：

（1）訂單服務(wù)投遞訊息給MQ中介軟體（2）物流服務(wù)監(jiān)聽MQ中介軟體，從而進(jìn)行消費(fèi)

我們這篇文章討論一下，如何保障訂單服務(wù)把訊息成功投遞給MQ中間件，以RabbitMQ舉例。

二、分析問(wèn)題

小夥伴們對(duì)此會(huì)有些疑問(wèn)，訂單服務(wù)發(fā)起訊息服務(wù)，回傳成功不就成功了嗎？如下面的偽代碼：

上面程式碼中，一般發(fā)送訊息就是這麼寫的，朋友們覺(jué)得有什麼問(wèn)題嗎？

下邊說(shuō)一個(gè)場(chǎng)景，如果MQ伺服器突然宕機(jī)了會(huì)出現(xiàn)什麼狀況？是不是我們訂單服務(wù)寄過(guò)去的訊息全部沒(méi)有了嗎？是的，一般MQ中間件為了提高系統(tǒng)的吞吐量會(huì)把訊息保存在記憶體中，如果不作其他處理，MQ伺服器一旦宕機(jī)，訊息就會(huì)全部遺失。這個(gè)是業(yè)務(wù)不允許的，造成很大的影響。

三、持久化

有經(jīng)驗(yàn)的小夥伴會(huì)說(shuō)，我知道一個(gè)方法就是把訊息持久化，RabbitMQ中發(fā)送訊息的時(shí)候會(huì)有個(gè)durable參數(shù)可以設(shè)置，設(shè)定為true，就會(huì)持久化。

這樣的話MQ伺服器即使宕機(jī)，重啟後磁碟檔案中有訊息的存儲(chǔ)，這樣就不會(huì)遺失了吧。是的這樣就一定機(jī)率的保障了訊息不遺失。

但還會(huì)有個(gè)場(chǎng)景，就是訊息剛剛儲(chǔ)存到MQ記憶體中，但還沒(méi)來(lái)得及更新到磁碟檔案中，突然宕機(jī)了。 （我靠，這個(gè)時(shí)間這麼短，也會(huì)出現(xiàn)，機(jī)率太低了吧），這個(gè)場(chǎng)景在持續(xù)的大量訊息投遞的過(guò)程中，會(huì)很常見(jiàn)。

那怎麼辦？我們要如何作才能保障一定會(huì)持久化到磁碟上面呢？

四、confirm機(jī)制

上面問(wèn)題出現(xiàn)在，沒(méi)有人告訴我們持久化是否成功。還好很多MQ有回呼通知的特性，RabbitMQ就有confirm機(jī)制來(lái)通知我們是否持久化成功？

confirm機(jī)制的原理：

（1）訊息生產(chǎn)者把訊息傳送給MQ，如果接收成功，MQ會(huì)回傳一個(gè)ack訊息給生產(chǎn)者；

（2）如果訊息接收不成功，MQ會(huì)回傳一個(gè)nack訊息給生產(chǎn)者；

上面的偽代碼，有兩個(gè)處理訊息方式，就是ack回調(diào)和nack回調(diào)。

這樣是不是就可以保障100%訊息不遺失了呢？

我們來(lái)看看confirm的機(jī)制，試想一下，如果我們生產(chǎn)者每發(fā)一則訊息，都要MQ持久化到磁碟中，然後再發(fā)起ack或nack的回呼。這樣的話是不是我們MQ的吞吐量很不高，因?yàn)槊看味家延嵪⒊志没酱诺小懭氪诺@個(gè)動(dòng)作是很慢的。這個(gè)在高並發(fā)場(chǎng)景下是不能夠接受的，吞吐量太低了。

所以MQ持久化磁碟真實(shí)的實(shí)現(xiàn)，是透過(guò)非同步呼叫處理的，他是有一定的機(jī)制，如：等到有幾千個(gè)訊息的時(shí)候，會(huì)一次性的刷盤到磁碟上面。而不是每來(lái)一則訊息，就刷盤一次。

所以comfirm機(jī)制其實(shí)是一個(gè)非同步監(jiān)聽的機(jī)制，是為了確保系統(tǒng)的高吞吐量，這樣就導(dǎo)致了還是不能夠100%保障訊息不遺失，因?yàn)榧词辜由狭薱onfirm機(jī)制，訊息在MQ記憶體中還沒(méi)刷盤到磁碟就宕機(jī)了，還是沒(méi)辦法處理。

說(shuō)了這麼多，還是沒(méi)辦法確保，那該怎麼辦呢？ ？ ？

五、訊息提前持久化 定時(shí)任務(wù)

#其實(shí)本質(zhì)的原因是無(wú)法確定是否持久化？那我們是不是可以自己讓消息持久化呢？答案是可以的，我們的方案再一步的演化。

上圖流程：

（1）訂單服務(wù)生產(chǎn)者再投遞訊息之前，先把訊息持久化到Redis或DB中，建議Redis ，高性能。訊息的狀態(tài)為發(fā)送中。

（2）confirm機(jī)制監(jiān)聽訊息是否發(fā)送成功？如ack成功訊息，刪除Redis中此訊息。

（3）如果nack不成功的訊息，這個(gè)可以根據(jù)自身的業(yè)務(wù)選擇是否重發(fā)此訊息。也可以刪除此訊息，由自己的業(yè)務(wù)決定。

（4）這邊加了個(gè)定時(shí)任務(wù)，來(lái)拉取隔一定時(shí)間了，訊息狀態(tài)還是為發(fā)送中的，這個(gè)狀態(tài)就表明，訂單服務(wù)是沒(méi)有收到ack成功訊息。

（5）定時(shí)任務(wù)會(huì)作補(bǔ)償性的投遞訊息。這時(shí)候如果MQ回呼ack成功接收了，再把Redis中這個(gè)訊息刪除。

這樣的機(jī)制其實(shí)就是補(bǔ)償機(jī)制，我不管MQ有沒(méi)有真正的接收到，只要我的Redis中的訊息狀態(tài)也是為【發(fā)送中】，就表示此訊息沒(méi)有正確成功投遞。再啟動(dòng)定時(shí)任務(wù)去監(jiān)控，發(fā)起補(bǔ)償投遞。

當(dāng)然定時(shí)任務(wù)那邊我們還可以加上一個(gè)補(bǔ)償?shù)拇螖?shù)，如果大於3次，還是沒(méi)有收到ack訊息，那就直接把訊息的狀態(tài)設(shè)定為【失敗】，由人工去排查到底是為什麼？

這樣的話方案就比較完美了，保障了100%的訊息不遺失（當(dāng)然不包含磁碟也壞了，可以做主從方案）。

不過(guò)這樣的方案，就會(huì)有可能發(fā)送多次相同的訊息，很有可能MQ已經(jīng)收到了訊息，就是ack訊息回呼時(shí)出現(xiàn)網(wǎng)路故障，沒(méi)有讓生產(chǎn)者收到。

那就要要求消費(fèi)者一定在消費(fèi)的時(shí)候保障冪等性！

六、冪等意義

我們先了解什麼叫冪等？在分散式應(yīng)用中，冪等是非常重要的，也就是相同條件下對(duì)一個(gè)業(yè)務(wù)的操作，不管操作多少次，結(jié)果都是一樣。

6.1、為什麼要有冪等這種場(chǎng)景？

為什麼要有冪等這種場(chǎng)景？因?yàn)樵诖笮偷南到y(tǒng)中，都是分散式部署，如：訂單業(yè)務(wù) 和 庫(kù)存業(yè)務(wù)有可能都是獨(dú)立部署的，都是單獨(dú)的服務(wù)。用戶下訂單，會(huì)呼叫到訂單服務(wù)和庫(kù)存服務(wù)。

因?yàn)榉稚⑹讲渴?，很有可能在呼叫?kù)存服務(wù)時(shí)，因?yàn)榫W(wǎng)路等原因，訂單服務(wù)呼叫失敗，但其實(shí)庫(kù)存服務(wù)已經(jīng)處理完成，只是返回給訂單服務(wù)處理結(jié)果時(shí)出現(xiàn)了異常。這時(shí)候一般系統(tǒng)會(huì)作補(bǔ)償方案，也就是訂單服務(wù)再此放起庫(kù)存服務(wù)的調(diào)用，庫(kù)存減1。

這樣就出現(xiàn)了問(wèn)題，其實(shí)上一次呼叫已經(jīng)減了1，只是訂單服務(wù)沒(méi)有收到處理結(jié)果。現(xiàn)在又呼叫一次，又要減1，這樣就不符合業(yè)務(wù)了，多扣了。

冪等這個(gè)概念就是，不管庫(kù)存服務(wù)在相同條件下呼叫幾次，處理結(jié)果都一樣。這樣才能保證補(bǔ)償方案的可行性。

6.2、樂(lè)觀鎖定方案

借鏡資料庫(kù)的樂(lè)觀鎖定機(jī)制，如：

根據(jù)version版本，也就是在操作庫(kù)存前先取得目前商品的version版本號(hào)，然後操作的時(shí)候帶上此version號(hào)。我們梳理下，我們第一次操作庫(kù)存時(shí)，得到version為1，調(diào)用庫(kù)存服務(wù)version變成了2；但返回給訂單服務(wù)出現(xiàn)了問(wèn)題，訂單服務(wù)又一次發(fā)起調(diào)用庫(kù)存服務(wù)，當(dāng)訂單服務(wù)傳如的version還是1，再執(zhí)行上面的sql語(yǔ)句時(shí)，就不會(huì)執(zhí)行；因?yàn)関ersion已經(jīng)變成2了，where條件就不成立。這樣就保證了不管呼叫幾次，只會(huì)真正的處理一次。

6.3、唯一ID 指紋碼

#原理就是利用資料庫(kù)主鍵去重，在業(yè)務(wù)完成後插入主鍵標(biāo)識(shí)

• #唯一ID就是業(yè)務(wù)表的唯一的主鍵，如商品ID

• 指紋碼就是為了區(qū)別每次正常操作的碼，每次操作時(shí)產(chǎn)生指紋碼；可以用時(shí)間戳 業(yè)務(wù)編號(hào)的方式。

上面的sql語(yǔ)句：

• #傳回如果為0 表示沒(méi)有操作過(guò)，那麼業(yè)務(wù)操作後就可以insert into t_check(唯一ID 指紋碼)

• #返回如果大於0 表示操作過(guò)，就直接回傳

##好處：實(shí)作簡(jiǎn)單

壞處：高並發(fā)下資料庫(kù)瓶頸

解決方案：根據(jù)ID進(jìn)行分庫(kù)分錶進(jìn)行演算法路由