【Java進階面試系列之四】扎心！線上服務宕機時，如何保證數據100%不丟失？【石杉的架構筆記】
歡迎關注個人公衆號：石杉的架構筆記（ID:shishan100）
週一至週五早8點半！精品技術文章準時送上！
一、寫在前面
上篇文章「Java進階面試系列之三」消息中間件在你們項目裏是如何落地的？，我們用一個簡單易懂的電商場景給大家引入說明了一個消息中間件的使用場景。
同時，我們還基於RabbitMQ的HelloWorld級別的代碼，給出了訂單服務和倉儲服務如何基於MQ中間件收發消息的示例。
二、業務場景回顧
這篇文章，我們來稍微深入探討一些MQ中間件使用中的基礎技術問題。
首先回顧一下上篇文章做出來的一個架構圖，看看訂單服務和消息服務是如何基於MQ來收發消息的。
我們稍微把這個圖細化一點，簡單來說就是多個訂單服務實例給queue推送消息，多個倉儲服務每個消費一部分消息。如下圖所示：
三、意外宕機，問題凸現
假如你線上對MQ技術的使用就到此爲止了，那麼基本可以跟offer說拜拜了。。。
因爲如果是我的話，作爲一個面試官就沒法繼續往下問了。你這個MQ的使用以及理解的深度僅此而已的話，那基本就是剛剛對MQ技術入門的程度。
如果面試官要繼續問，完全可以問下面的問題：
那你說說如果倉儲服務作爲消費者服務，剛收到了一個訂單消息，但是在完成消息的處理之前，也就是還沒對訂單完成倉儲調度發貨，結果這個倉儲服務突然就宕機了，這個時候會發生什麼事情？
所以說，大家還是要對這個技術瞭解的稍微深入一點點，否則隨便被問幾個問題就完蛋了。
大夥兒先來看看下面的圖，感受一下車禍現場。
RabbitMQ這個中間件默認的一個行爲，就是隻要倉儲服務收到一個訂單消息，RabbitMQ就會立馬把這條訂單消息給標記爲刪除，這個行爲叫做自動ack，也就是投遞完成一條消息就自動確認這個消息處理完畢了。
但是接着如果此時倉儲服務收到了一個訂單消息，但是還沒來得及對倉庫系統完成商品的調度發貨，結果直接就宕機了。
此時，明顯這個訂單消息就丟失了啊，因爲RabbitMQ那裏已經沒有了。。。
這會導致什麼樣的尷尬體驗呢？就是一個用戶支付了8999元，對一個iphone8下了訂單，結果呢，死等活等了好幾天，就是不見網站上顯示他的iphone8在發貨。
搞了半天，原因就是他的那個iphone8的訂單在倉儲服務那裏，還沒來得及調度發貨直接就宕機了，導致這個訂單消息就一直丟失了，始終沒有給這個用戶通知倉庫系統進行發貨。
這個問題，是不是很尷尬？所以說，技術問題是會嚴重影響企業的核心業務流程的！
各位小夥伴，還記得上一講咱們的倉儲服務消費消息的代碼中，有一行關鍵的代碼：
這行代碼對channel.basicConsume()方法，傳入的第二個參數：true，其實就是一個關鍵的參數。
這個true就代表了一個核心的含義，他的意思是，RabbitMQ只要把一個消息投遞到倉儲服務手上，立馬就標記這個消息刪除了。
但是在這個默認的配置之下，要是倉儲服務收到一個訂單消息，結果還沒來得及完成耗時幾十秒的倉儲調度發貨的業務邏輯，結果突然宕機了，那麼這個訂單消息就永久性丟失了！
找了半天，原來問題的癥結在這裏啊！大家是不是明白了，上一篇文章最後爲什麼我會說，這個代碼目前爲止還有很多的問題。
所以這個時候，我們如果希望不要因爲倉儲服務的突然宕機導致一條訂單消息丟失，就需要改造一下倉儲服務消費消息的代碼了。
首先，我們需要把那個參數從true改爲false，如下代碼所示：
只要修改爲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、參數來進行合理設置，確保消息不要隨意丟失。
END
如有收穫，請幫忙轉發，您的鼓勵是作者最大的動力，謝謝！
一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上
歡迎掃描下方二維碼，持續關注：