一、寫在前面

之前寫過一篇文章??《項(xiàng)目里接入了MQ消息中間件以后，我摸魚的時(shí)間更長了~》??，我們用一個(gè)簡單易懂的電商場景給大家引入說明了一個(gè)消息中間件的使用場景。

同時(shí)，我們還基于RabbitMQ的HelloWorld級別的代碼，給出了訂單服務(wù)和倉儲(chǔ)服務(wù)如何基于MQ中間件收發(fā)消息的示例。

二、業(yè)務(wù)場景回顧

這篇文章，我們來稍微深入探討一些MQ中間件使用中的基礎(chǔ)技術(shù)問題。

首先回顧一下上篇文章做出來的一個(gè)架構(gòu)圖，看看訂單服務(wù)和消息服務(wù)是如何基于MQ來收發(fā)消息的。

我們稍微把這個(gè)圖細(xì)化一點(diǎn)，簡單來說就是多個(gè)訂單服務(wù)實(shí)例給queue推送消息，多個(gè)倉儲(chǔ)服務(wù)每個(gè)消費(fèi)一部分消息。如下圖所示：

三、意外宕機(jī)，問題凸現(xiàn)

假如你線上對MQ技術(shù)的使用就到此為止了，那么基本可以跟offer說拜拜了。。。

因?yàn)槿绻俏业脑?，作為一個(gè)面試官就沒法繼續(xù)往下問了。你這個(gè)MQ的使用以及理解的深度僅此而已的話，那基本就是剛剛對MQ技術(shù)入門的程度。

如果面試官要繼續(xù)問，完全可以問下面的問題：

• 那你說說如果倉儲(chǔ)服務(wù)作為消費(fèi)者服務(wù)，剛收到了一個(gè)訂單消息，但是在完成消息的處理之前，也就是還沒對訂單完成倉儲(chǔ)調(diào)度發(fā)貨，結(jié)果這個(gè)倉儲(chǔ)服務(wù)突然就宕機(jī)了，這個(gè)時(shí)候會(huì)發(fā)生什么事情？

所以說，大家還是要對這個(gè)技術(shù)了解的稍微深入一點(diǎn)點(diǎn)，否則隨便被問幾個(gè)問題就完蛋了。

大伙兒先來看看下面的圖，感受一下車禍現(xiàn)場。

?RabbitMQ這個(gè)中間件默認(rèn)的一個(gè)行為，就是只要倉儲(chǔ)服務(wù)收到一個(gè)訂單消息，RabbitMQ就會(huì)立馬把這條訂單消息給標(biāo)記為刪除，這個(gè)行為叫做自動(dòng)ack，也就是投遞完成一條消息就自動(dòng)確認(rèn)這個(gè)消息處理完畢了。

但是接著如果此時(shí)倉儲(chǔ)服務(wù)收到了一個(gè)訂單消息，但是還沒來得及對倉庫系統(tǒng)完成商品的調(diào)度發(fā)貨，結(jié)果直接就宕機(jī)了。

此時(shí)，明顯這個(gè)訂單消息就丟失了啊，因?yàn)镽abbitMQ那里已經(jīng)沒有了。。。

這會(huì)導(dǎo)致什么樣的尷尬體驗(yàn)?zāi)兀烤褪且粋€(gè)用戶支付了8999元，對一個(gè)iphone8下了訂單，結(jié)果呢，死等活等了好幾天，就是不見網(wǎng)站上顯示他的iphone8在發(fā)貨。

搞了半天，原因就是他的那個(gè)iphone8的訂單在倉儲(chǔ)服務(wù)那里，還?沒來得及調(diào)度發(fā)貨直接就宕機(jī)了，導(dǎo)致這個(gè)訂單消息就一直丟失了，始終沒有給這個(gè)用戶通知倉庫系統(tǒng)進(jìn)行發(fā)貨。

這個(gè)問題，是不是很尷尬？所以說，技術(shù)問題是會(huì)嚴(yán)重影響企業(yè)的核心業(yè)務(wù)流程的！

各位小伙伴，還記得上一講咱們的倉儲(chǔ)服務(wù)消費(fèi)消息的代碼中，有一行關(guān)鍵的代碼：

?這行代碼對channel.basicConsume()方法，傳入的第二個(gè)參數(shù)：true，其實(shí)就是一個(gè)關(guān)鍵的參數(shù)。

這個(gè)true就代表了一個(gè)核心的含義，他的意思是，RabbitMQ只要把一個(gè)消息投遞到倉儲(chǔ)服務(wù)手上，立馬就標(biāo)記這個(gè)消息刪除了。

但是在這個(gè)默認(rèn)的配置之下，要是倉儲(chǔ)服務(wù)收到一個(gè)訂單消息，結(jié)果還沒來得及完成耗時(shí)幾十秒的倉儲(chǔ)調(diào)度發(fā)貨的業(yè)務(wù)邏輯，結(jié)果突然宕機(jī)了，那么這個(gè)訂單消息就永久性丟失了！

找了半天，原來問題的癥結(jié)在這里??！大家是不是明白了，上一篇文章最后為什么我會(huì)說，這個(gè)代碼目前為止還有很多的問題。

所以這個(gè)時(shí)候，我們?nèi)绻Ｍ灰驗(yàn)閭}儲(chǔ)服務(wù)的突然宕機(jī)導(dǎo)致一條訂單消息丟失，就需要改造一下倉儲(chǔ)服務(wù)消費(fèi)消息的代碼了。?

首先，我們需要把那個(gè)參數(shù)從true改為false，如下代碼所示：

?只要修改為false之后，RabbitMQ就不會(huì)盲目的投遞消息到倉儲(chǔ)服務(wù)，立馬就刪除消息了，說白了就是關(guān)閉autoAck的行為，不要自作主張的認(rèn)為消息處理成功了。

接著，我們需要改造一下處理訂單消息的代碼，如下代碼所示。

這段代碼，說白了，就是在對訂單完成了調(diào)度發(fā)貨之后，在finally代碼塊中手動(dòng)執(zhí)行了ack操作，說我自己已經(jīng)完成了耗時(shí)幾十秒的業(yè)務(wù)邏輯的處理，現(xiàn)在可以手動(dòng)ack通知RabbitMQ，這個(gè)消息處理完畢了。?

此時(shí)整個(gè)架構(gòu)運(yùn)行流程大致看起來跟下面的圖那樣子。

架構(gòu)流程改成上面那樣后，就意味著只有完成了倉儲(chǔ)調(diào)度發(fā)貨的代碼業(yè)務(wù)邏輯，確保倉庫系統(tǒng)收到通知之后，倉儲(chǔ)服務(wù)才會(huì)在代碼中手動(dòng)發(fā)送ack消息給RabbitMQ。

此時(shí)，RabbitMQ收到了這個(gè)ack消息，才會(huì)標(biāo)記對應(yīng)的訂單消息被刪除了。

如果說在倉儲(chǔ)服務(wù)收到了訂單消息，但是還沒來得及完成倉儲(chǔ)調(diào)度發(fā)貨的業(yè)務(wù)邏輯，那也就絕對不會(huì)執(zhí)行這條訂單消息的ack操作，然后RabbitMQ也就不會(huì)收到這條訂單消息的ack通知。

一旦RabbitMQ發(fā)現(xiàn)代表消費(fèi)者的某個(gè)倉儲(chǔ)服務(wù)實(shí)例突然宕機(jī)了，而這個(gè)倉儲(chǔ)服務(wù)收到的一些訂單消息還沒來得及處理，沒給自己發(fā)送那些消息的ack通知。

此時(shí)，RabbitMQ會(huì)自動(dòng)對這條訂單消息重發(fā)推送給其他在運(yùn)行中的倉儲(chǔ)服務(wù)實(shí)例，讓其他的倉儲(chǔ)服務(wù)實(shí)例去處理這條訂單消息。

這樣的話，就可以保證這條訂單消息不會(huì)因?yàn)槟硞€(gè)倉儲(chǔ)服務(wù)實(shí)例的宕機(jī)而丟失，他會(huì)確保必須由某個(gè)倉儲(chǔ)服務(wù)實(shí)例完成這條訂單消息的調(diào)度發(fā)貨處理，然后才會(huì)刪除那條訂單消息。

四、總結(jié) tips

最后再來一張圖，大家直觀的感受一下：

好了，各位同學(xué)，這篇文章是不是相對稍微深入一點(diǎn)點(diǎn)，讓大家了解到了一些使用MQ技術(shù)時(shí)候要考慮的一些問題？

實(shí)際上無論是RocketMQ、Kafka還是RabbitMQ，都有類似的autoAck或者是手動(dòng)ack的機(jī)制。

?線上生產(chǎn)環(huán)境中運(yùn)行時(shí)，你必須要考慮到消費(fèi)者服務(wù)可能宕機(jī)的問題。

如果消費(fèi)者服務(wù)沒處理完消息就自己宕機(jī)了，那么一定會(huì)導(dǎo)致部分消息的丟失?，進(jìn)而影響核心業(yè)務(wù)流程的運(yùn)轉(zhuǎn)。

因此大家在線上使用MQ時(shí)，一定要充分考慮這些潛在問題，同時(shí)結(jié)合具體的MQ提供的一些API、參數(shù)來進(jìn)行合理設(shè)置，確保消息不要隨意丟失。