一、寫在前面

上篇文章《同學，消息中間件在你們生產項目里如何落地使用的？》，我們用一個簡單易懂的電商場景給大家引入說明了一個消息中間件的使用場景。

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

二、業務場景回顧

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

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

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

三、意外宕機，問題凸現

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

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

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

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

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

大伙兒先來看看下面的圖，感受一下車禍現場。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四、總結 tips

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

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

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

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

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

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