這個問題，在網際網路公司面試的時候高頻出現，而且也是非常現實的生產環境問題。
如果你的簡歷中寫了自己熟悉mq技術（rabbitmq、rocketmq、kafka），而且在專案裡有使用的經驗，那麼非常實際的乙個生產環境問題就是：投遞訊息到mq，然後從mq消費訊息來處理的這個過程，資料到底會不會丟失。
面試官此時會問：如果資料會丟失的話，你們專案生產部署的時候，是通過什麼手段保證基於mq傳輸的資料100%不會丟失的？麻煩結合你們線上使用的訊息中介軟體來具體說說你們的技術方案。
這個其實就是非常區分面試候選人技術水平的乙個問題。
實際上相當大比例的普通工程師，哪怕是在一些中小型網際網路公司裡工作過的，也就是基於公司部署的mq集群簡單的使用一下罷了，可能**層面就是基本的傳送訊息和消費訊息，基本沒考慮太多的技術方案。
但是實際上，對於mq、快取、分庫分表、nosql等各式各類的技術以及中介軟體在使用的時候，都會有對應技術相關的一堆生產環境問題。
那麼針對這些問題，就必須要有相對應的一整套技術方案來保證系統的健壯性、穩定性以及高可用性。
所以其實中大型網際網路公司的面試官在面試候選人的時候，如果考察對mq相關技術的經驗和掌握程度，十有**都會丟擲這個使用mq時一定會涉及的資料丟失問題。因為這個問題，能夠非常好的區分候選人的技術水平。
所以這篇文章，我們就來具體聊聊基於rabbitmq這種訊息中介軟體的背景下，從投遞訊息到mq，到從mq消費訊息出來，這個過程中有哪些資料丟失的風險和可能。
《哥們，你們的系統架構中為什麼要引入訊息中介軟體？》
《哥們，那你說說系統架構引入訊息中介軟體有什麼缺點？》
《哥們，訊息中介軟體在你們專案裡是如何落地的？》
我們分別從消費者突然宕機可能導致資料丟失，以及集群突然崩潰可能導致的資料丟失兩個角度討論了一下資料如何不丟失。
《扎心！線上服務宕機時，如何保證資料100%不丟失？》
《訊息中介軟體集群崩潰，如何保證百萬生產資料不丟失？》
總之，希望對mq不太熟悉的同學，先把前面那些系列文章熟悉一下，然後再來一起系統性的研究一下mq資料如何做到100%不丟失。
經過之前幾篇文章的討論，目前我們已經初步知道，第乙個會導致資料丟失的地方，就是消費者獲取到訊息之後，沒有來得及處理完畢，自己直接宕機了。
此時rabbitmq的自動ack機制會通知mq集群這條訊息已經處理好了，mq集群就會刪除這條訊息。
那麼這條訊息不就丟失了麼？不會有任何乙個消費者處理到這條訊息了。
所以之前我們詳細討論過，通過在消費者服務中調整為手動ack機制，來確保訊息一定是已經成功處理完了，才會傳送ack通知給mq集群。
否則沒傳送ack之前消費者服務宕機，此時mq集群會自動感知到，然後重發訊息給其他的消費者服務例項。
當時除了這個資料丟失問題之外，還有另外乙個問題，就是mq集群自身如果突然宕機，是不是會導致資料丟失？
預設情況下是肯定會的，因為queue和message都沒採用持久化的方式來投遞，所以mq集群重啟會導致部分資料丟失。
所以《訊息中介軟體集群崩潰，如何保證百萬生產資料不丟失？》這篇文章，我們分析了如何採用持久化的方式來建立queue，同時採用持久化的方式來投遞訊息到mq集群，這樣mq集群會將訊息持久化到磁碟上去。
此時如果訊息還沒來得及投遞給消費者服務，然後mq集群突然宕機了，資料是不會丟失的，因為mq集群重啟之後會自動從磁碟檔案裡載入出來沒投遞出去的訊息，然後繼續投遞給消費者服務。
同樣，該方案沉澱下來的系統架構圖，如下所示：
大家想一想，到目前為止，咱們的架構一定可以保證資料不丟失了嗎？
其實，現在的架構，還是有乙個資料可能會丟失的問題。
那就是上面作為生產者的訂單服務把訊息投遞到mq集群之後，暫時還駐留在mq的記憶體裡，還沒來得及持久化到磁碟上，同時也還沒來得及投遞到作為消費者的倉儲服務。
此時要是mq集群自身突然宕機，咋辦呢？
尷尬了吧，駐留在記憶體裡的資料是一定會丟失的，我們來看看下面的圖示。
現在，我們需要考慮的技術方案是：訂單服務如何保證訊息一定已經持久化到磁碟？
實際上，作為生產者的訂單服務把訊息投遞到mq集群的過程是很容易丟資料的。
比如說網路出了點什麼故障，資料壓根兒沒傳輸過去，或者就是上面說的訊息剛剛被mq接收但是還駐留在記憶體裡，沒落地到磁碟上，此時mq集群宕機就會丟資料。
所以首先，我們得考慮一下作為生產者的訂單服務要如何利用rabbitmq提供的相關功能來實現乙個技術方案。
這個技術方案需要保證：只要訂單服務傳送出去的訊息確認成功了，此時mq集群就一定已經將訊息持久化到磁碟了。
我們必須實現這樣的乙個效果，才能保證投遞到mq集群的資料是不會丟失的。
這裡我們需要研究的技術細節是：倉儲服務手動ack保證資料不丟失的實現原理。
之前，筆者就收到很多同學提問：
倉儲服務那塊到底是如何基於手動ack就可以實現資料不丟失的？
rabbitmq底層實現的細節和原理到底是什麼？
為什麼倉儲服務沒傳送ack就宕機了，rabbitmq可以自動感知到他宕機了，然後自動重發訊息給其他的倉儲服務例項呢？
這些東西背後的實現原理和底層細節，到底是什麼？
大夥兒稍安勿躁，接下來，咱們會通過一系列文章，仔細**一下這背後的原理。
訊息中介軟體（1）
在深入了解訊息中介軟體之前，我想先搞清楚為什麼會出現訊息中介軟體這麼一款產品，換句話說我們需要弄清楚訊息中介軟體到底解決了乙個什麼問題。在網際網路的初級階段，那個時候一方面沒有想現在如此多的使用者，另一方面也沒有太複雜的業務場景，在那個階段，應用的架構往往是垂直式的，通俗的講就是在乙個工程中解決所有...
知識鏈 訊息中介軟體
訊息中介軟體 kafka kafka它本質上是乙個訊息系統，不同於傳統的企業資訊佇列系統，它是以近乎實時的方式處理流經乙個公司的所有資料，目前已經服務於linkedin netflix uber以及verizon，並為此建立了實時資訊處理平台。應用場景 1.kafka可以應用於訊息系統，比如，當下較...
學習筆記 訊息中介軟體（1）
介紹 訊息中介軟體是訊息的傳輸過程中儲存訊息的容器。訊息中介軟體再將訊息從它的源中繼到它的目標時充當中間人的作用。佇列的主要目的是提供路由並保證訊息的傳遞 如果傳送訊息時接收者不可用，訊息佇列會保留，直到可以成功地傳遞它為止，當然訊息佇列儲存訊息也是有限的。特點 1 採用非同步處理模式 訊息傳送者可...