背景引入
這篇文章，我們來聊聊在線上生產環境使用消息中間件技術的時候，從前到后的全鏈路到底如何保證數據不能丟失。
這個問題，在互聯網公司面試的時候高頻出現，而且也是非常現實的生產環境問題。
如果你的簡歷中寫了自己熟悉MQ技術（RabbitMQ、RocketMQ、Kafka），而且在項目里有使用的經驗，那么非常實際的一個生產環境問題就是：投遞消息到MQ，然后從MQ消費消息來處理的這個過程，數據到底會不會丟失。
面試官此時會問：如果數據會丟失的話，你們項目生產部署的時候，是通過什么手段保證基於MQ傳輸的數據100%不會丟失的？麻煩結合你們線上使用的消息中間件來具體說說你們的技術方案。
這個其實就是非常區分面試候選人技術水平的一個問題。
實際上相當大比例的普通工程師，哪怕是在一些中小型互聯網公司里工作過的，也就是基於公司部署的MQ集群簡單的使用一下罷了，可能代碼層面就是基本的發送消息和消費消息，基本沒考慮太多的技術方案。
但是實際上，對於MQ、緩存、分庫分表、NoSQL等各式各類的技術以及中間件在使用的時候，都會有對應技術相關的一堆生產環境問題。
那么針對這些問題，就必須要有相對應的一整套技術方案來保證系統的健壯性、穩定性以及高可用性。
所以其實中大型互聯網公司的面試官在面試候選人的時候，如果考察對MQ相關技術的經驗和掌握程度，十有八九都會拋出這個使用MQ時一定會涉及的數據丟失問題。因為這個問題，能夠非常好的區分候選人的技術水平。
所以這篇文章，我們就來具體聊聊基於RabbitMQ這種消息中間件的背景下，從投遞消息到MQ，到從MQ消費消息出來，這個過程中有哪些數據丟失的風險和可能。
然后我們再一起來看看，應該如何結合MQ自身提供的一些技術特性來保證數據不丟失？
前情回顧
首先給大伙一點提醒，有些新同學可能還對MQ相關技術不太了解，建議看一下之前的MQ系列文章，看看MQ的基本使用和原理：
另外，其實之前我們有過2篇文章是討論消息中間件的數據不丟失問題的。
我們分別從消費者突然宕機可能導致數據丟失，以及集群突然崩潰可能導致的數據丟失兩個角度討論了一下數據如何不丟失。
只不過僅僅那兩個方案還無法保證全鏈路數據不丟失，但是大家如果沒看過的建議也先回過頭看看：
總之，希望對MQ不太熟悉的同學，先把前面那些系列文章熟悉一下，然后再來一起系統性的研究一下MQ數據如何做到100%不丟失。
目前已有的技術方案
經過之前幾篇文章的討論，目前我們已經初步知道，第一個會導致數據丟失的地方，就是消費者獲取到消息之后，沒有來得及處理完畢，自己直接宕機了。
此時RabbitMQ的自動ack機制會通知MQ集群這條消息已經處理好了，MQ集群就會刪除這條消息。
那么這條消息不就丟失了么？不會有任何一個消費者處理到這條消息了。
所以之前我們詳細討論過，通過在消費者服務中調整為手動ack機制，來確保消息一定是已經成功處理完了，才會發送ack通知給MQ集群。
否則沒發送ack之前消費者服務宕機，此時MQ集群會自動感知到，然后重發消息給其他的消費者服務實例。
《扎心！線上服務宕機時，如何保證數據100%不丟失？》這篇文章，詳細討論了這個問題，手動ack機制之下的架構圖如下所示：
當時除了這個數據丟失問題之外，還有另外一個問題，就是MQ集群自身如果突然宕機，是不是會導致數據丟失？
默認情況下是肯定會的，因為queue和message都沒采用持久化的方式來投遞，所以MQ集群重啟會導致部分數據丟失。
所以《消息中間件集群崩潰，如何保證百萬生產數據不丟失？》這篇文章，我們分析了如何采用持久化的方式來創建queue，同時采用持久化的方式來投遞消息到MQ集群，這樣MQ集群會將消息持久化到磁盤上去。
此時如果消息還沒來得及投遞給消費者服務，然后MQ集群突然宕機了，數據是不會丟失的，因為MQ集群重啟之后會自動從磁盤文件里加載出來沒投遞出去的消息，然后繼續投遞給消費者服務。
同樣，該方案沉淀下來的系統架構圖，如下所示：
數據100%不丟失了嗎？
大家想一想，到目前為止，咱們的架構一定可以保證數據不丟失了嗎？
其實，現在的架構，還是有一個數據可能會丟失的問題。
那就是上面作為生產者的訂單服務把消息投遞到MQ集群之后，暫時還駐留在MQ的內存里，還沒來得及持久化到磁盤上，同時也還沒來得及投遞到作為消費者的倉儲服務。
此時要是MQ集群自身突然宕機，咋辦呢？
尷尬了吧，駐留在內存里的數據是一定會丟失的，我們來看看下面的圖示。
按需制定技術方案
現在，我們需要考慮的技術方案是：訂單服務如何保證消息一定已經持久化到磁盤？
實際上，作為生產者的訂單服務把消息投遞到MQ集群的過程是很容易丟數據的。
比如說網絡出了點什么故障，數據壓根兒沒傳輸過去，或者就是上面說的消息剛剛被MQ接收但是還駐留在內存里，沒落地到磁盤上，此時MQ集群宕機就會丟數據。
所以首先，我們得考慮一下作為生產者的訂單服務要如何利用RabbitMQ提供的相關功能來實現一個技術方案。
這個技術方案需要保證：只要訂單服務發送出去的消息確認成功了，此時MQ集群就一定已經將消息持久化到磁盤了。
我們必須實現這樣的一個效果，才能保證投遞到MQ集群的數據是不會丟失的。
需要研究的技術細節
這里我們需要研究的技術細節是：倉儲服務手動ack保證數據不丟失的實現原理。
之前，筆者就收到很多同學提問：
- 倉儲服務那塊到底是如何基於手動ack就可以實現數據不丟失的？
- RabbitMQ底層實現的細節和原理到底是什么？
- 為什么倉儲服務沒發送ack就宕機了，RabbitMQ可以自動感知到他宕機了，然后自動重發消息給其他的倉儲服務實例呢？
這些東西背后的實現原理和底層細節，到底是什么？
大伙兒稍安勿躁，接下來，咱們會通過一系列文章，仔細探究一下這背后的原理。
互聯網面試必殺：如何保證消息中間件全鏈路數據100%不丟失：第二篇
互聯網面試必殺：如何保證消息中間件全鏈路數據100%不丟失：第三篇
互聯網面試必殺：如何保證消息中間件全鏈路數據100%不丟失：第四篇
來源：【微信公眾號 - 石杉的架構筆記】