通過之前文章的閱讀，有關rocketmq的底層原理相信小夥伴們已經有了乙個比較清晰的認識。
那麼接下來王子想跟大家討論乙個話題，如果我們的專案中引入了mq，勢必要面對的乙個問題，就是訊息丟失問題
，今天我們就來聊聊訊息是怎麼丟失的。
現在假設我們的業務是這樣的，使用者通過訂單系統下了乙個訂單，訂單系統完成支付後會傳送訊息給rocketmq，然後積分系統會從rocketmq中消費訊息，去給使用者增加積分，如下圖：
但是突然有一天有使用者反映，支付訂單之後，自己的積分並沒有增長，這是為什麼呢？
經過排查日誌，我們只發現了推送訊息給mq的日誌，而沒有發現積分系統消費這條訊息的日誌，這就導致了積分系統並沒有給使用者發放積分。
也就是說，訊息在傳輸過程中丟失了。
在系統的核心鏈路中，如果發生訊息丟失的問題，可能會產生惡劣的後果，為了解決此類問題，我們必須弄明白什麼時候會發生訊息丟失。
我們先來看一下整個流程的第一步，訂單系統在支付成功之後，一定會把支付成功的訊息推送給mq，那麼在這個推送的過程中，訊息可能丟失嗎？
答案是肯定的，一定會存在訊息丟失的情況。
比較常見的情況就是網路抖動，在推送訊息這一過程中是通過網路進行通訊的，那麼這個時候如果恰巧網路出現了故障，導致通訊失敗了，那麼這個訊息必然就不會成功的推送到mq中。
那除了網路抖動外，還有沒有其他的情況導致推送失敗呢？
其實情況有很多，比如mq成功接收到了訊息，但是mq本身的網路模組的**出現了異常，可能是內部實現的bug,導致訊息沒有成功處理。
或者當我們推送訊息給乙個mq的主從集群的時候，剛好遇到leader節點出現故障，其他的follower正在嘗試切換為leader，這個過程中也可能導致訊息丟失。
類似的問題還有其他的。
所以我們首先要明確一點，無論我們使用任何mq中介軟體的時候，你傳送出的訊息都不一定能成功，而失敗的時候有可能會在你的**裡發生異常，也有可能不會丟擲異常，具體要看什麼情況導致的傳送失敗。
接下來假設我們訂單系統推送到mq這一過程沒有任何問題，訊息成功到達了mq中，此時訂單系統會認為訊息寫入成功了，那麼這時候訊息就一定不會丟失了嗎？
答案是否定的，這個時候也不能保證訊息的不丟失，我們來分析一下。
通過之前文章的了解，相信大家都還記得，當訊息寫入到mq後，mq會把訊息先寫入到os cache，也就是作業系統的快取區中，本質也是記憶體，如下圖：
也就是說，你認為傳送成功的訊息，可能只存在於記憶體中，還沒到磁碟中。
那麼如果這個時候機器宕機了，os cache中的訊息資料將會跟著丟失掉，是不是這個理。
那麼現在假設訊息已經重新整理到磁碟上了，是不是就可以保證萬無一失了呢？
顯然這個時候也是不能完全保證的，因為雖然你把資料儲存到了磁碟中，但是如果磁碟發生了故障，資料還是會丟失掉。
如果大家平時有了解一下新聞熱點，會聽說過某某網際網路公司，由於資料儲存在磁碟上沒有冗餘備份，結果磁碟發生故障導致好多年的核心資料全部丟失，大量工作都功虧一簣，這就是血淋淋的教訓。
那麼到現在，經歷了重重困境，假設積分系統終於能夠消費到這條訊息了，那麼它就能安穩的把積分正常的發放給使用者嗎？
答案依然是否定的。
看過之前文章的小夥伴們應該還記得消費者在進行消費時，是有乙個offset的概念的。
這個offset說白了就是個進度標識，讓mq知道消費者消費到了哪，下次好接著向下消費。
現在假設我們有兩條訊息，offset為1和2。
假設我們的積分系統接收到了訊息1，那麼訊息1就在積分系統的記憶體中，正要準備給使用者發放積分。
而預設情況下，消費者會自動提交已經消費的訊息的offset，所以當積分系統獲取訊息後，可能直接就把訊息1的offset提交給了mq，標識為已經處理了這條訊息。
那麼此時，如果積分系統突然宕機，還未發放積分給使用者，那麼這條訊息1自然就丟失了，因為mq已經把他標記成了已處理，實際積分系統還未處理。
所以消費者獲得訊息後也是可能發生訊息丟失的。
好了，看過今天的文章，相信小夥伴們對於rocketmq的訊息是怎麼丟失的會有乙個更深刻的印象。
總結起來就是以下幾點：
1.生產者傳送訊息到mq這一過程導致訊息丟失
2.mq自己發生故障導致訊息丟失
3.消費者拿到訊息後，由於操作不當導致訊息丟失
所以任何的技術引入生產環境都是有風險的，引入前我們一定要做好功課。
今天的文章就說到這，小夥伴們可能會問王子，聊了這麼多，到底應該如何解決掉訊息丟失的問題呢？
別急，我們下篇文章就會有解決方案了。
往期文章推薦：
什麼是訊息中介軟體？主要作用是什麼？
常見的訊息中介軟體有哪些？你們是怎麼進行技術選型的？
你懂rocketmq 的架構原理嗎？
聊一聊rocketmq的註冊中心nameserver
broker的主從架構是怎麼實現的？
rocketmq生產部署架構如何設計
rabbitmq和kafka的高可用集群原理
rocketmq的傳送模式和消費模式
討論一下秒殺系統的技術難點與解決方案
秒殺系統中的扣減庫存和流量削峰
深入研究rocketmq生產者傳送訊息的底層原理
深入研究broker是如何持久化的
dledger是如何實現主從自動切換的
深入研究rocketmq消費者是如何獲取訊息的
rocketmq的訊息訪問
rocketmq是我們常用的訊息中介軟體之一，現在我們就來分析一下，它是如何儲存和讀取訊息的。rocketmq是把訊息持久化在本地的檔案系統的，所有的訊息，都儲存在commitlog檔案中，這個檔案是不區分topic或者messagequeue的，所有的訊息，都是儲存在一起，這個點跟常見的kafka...
RocketMQ的事務訊息處理
producer 傳送half message到broker中 broker接收到half message後給producer傳送成功的發聵，這時，half message才算真正生成完了 producer執行本地事務 producer根據第3步得到執行本地事務的結果，向mq進行二次確認 到底是co...
rocketmq廣播訊息的（五）
廣播消費指的是 一條訊息被多個consumer消費，即使這些consumer屬於同乙個consumergroup,訊息也會被consumergroup中的每個consumer都消費一次，廣播消費中consumergroup概念可以認為在訊息劃分方面無意義。發布訂閱訊息生產者 public class...