一、寫在前面

之前寫過一篇文章《??RabbitMQ是如何收發(fā)消息的？(通俗易懂)??》，我們用一個簡單易懂的電商場景給大家引入說明了一個消息中間件的使用場景。

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

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

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

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

我們稍微把這個圖細化一點，簡單來說就是多個訂單服務實例給queue推送消息，多個倉儲服務每個消費一部分消息。如下圖所示：

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

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

因為如果是我的話，作為一個面試官就沒法繼續(xù)往下問了。你這個MQ的使用以及理解的深度僅此而已的話，那基本就是剛剛對MQ技術入門的程度。

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

那你說說如果倉儲服務作為消費者服務，剛收到了一個訂單消息，但是在完成消息的處理之前，也就是還沒對訂單完成倉儲調度發(fā)貨，結果這個倉儲服務突然就宕機了，這個時候會發(fā)生什么事情？

所以說，大家還是要對這個技術了解得稍微深入一點點，否則隨便被問幾個問題就完蛋了。

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

RabbitMQ這個中間件默認的一個行為，就是只要倉儲服務收到一個訂單消息，RabbitMQ就會立馬把這條訂單消息給標記為刪除，這個行為叫做自動ack，也就是投遞完成一條消息就自動確認這個消息處理完畢了。

但是接著如果此時倉儲服務收到了一個訂單消息，但是還沒來得及對倉庫系統(tǒng)完成商品的調度發(fā)貨，結果直接就宕機了。

此時，明顯這個訂單消息就丟失了啊，因為RabbitMQ那里已經沒有了。。。

這會導致什么樣的尷尬體驗呢？就是一個用戶支付了8999元，對一個iphone8下了訂單，結果呢，死等活等了好幾天，就是不見網(wǎng)站上顯示他的iphone8在發(fā)貨。

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

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

各位小伙伴，還記得上一講咱們的倉儲服務消費消息的代碼中，有一行關鍵的代碼：

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

這個true就代表了一個核心的含義，他的意思是，RabbitMQ只要把一個消息投遞到倉儲服務手上，立馬就標記這個消息刪除了。

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

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

所以這個時候，我們如果希望不要因為倉儲服務的突然宕機導致一條訂單消息丟失，就需要改造一下倉儲服務消費消息的代碼了。

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

只要修改為false之后，RabbitMQ就不會盲目的投遞消息到倉儲服務，立馬就刪除消息了，說白了就是關閉autoAck的行為，不要自作主張的認為消息處理成功了。

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

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

此時整個架構運行流程大致看起來跟下面的圖那樣子。

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

此時，RabbitMQ收到了這個ack消息，才會標記對應的訂單消息被刪除了。

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

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

此時，RabbitMQ會自動對這條訂單消息重發(fā)推送給其他在運行中的倉儲服務實例，讓其他的倉儲服務實例去處理這條訂單消息。

這樣的話，就可以保證這條訂單消息不會因為某個倉儲服務實例的宕機而丟失，他會確保必須由某個倉儲服務實例完成這條訂單消息的調度發(fā)貨處理，然后才會刪除那條訂單消息。

四、總結 tips

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

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

實際上無論是RocketMQ、Kafka還是RabbitMQ，都有類似的autoAck或者是手動ack的機制。

線上生產環(huán)境中運行時，你必須要考慮到消費者服務可能宕機的問題。

如果消費者服務沒處理完消息就自己宕機了，那么一定會導致部分消息的丟失，進而影響核心業(yè)務流程的運轉。

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