前言
之前我們一起了解了使用RocketMQ事務消息解決生產者發送消息時消息丟失的問題，但使用了事務消息後消息就一定不會丟失了嗎，肯定是不能保證的。
因爲雖然我們解決了生產者發送消息時候的消息丟失問題，但也只是保證Broker正確的接收到了消息，實際上接收到的消息會保存在os cache中，如果此時broker機器突然宕機，os cache中的消息數據就丟失掉了。
而且就算是os cache中的消息已經刷盤到了磁盤中，如果磁盤突然就壞了，消息是不是也就丟失了。
所以我們還要考慮Broker如何保證消息不丟失。
Broker的消息丟失解決方案
說到這裏，我們就進入主題了，首先解決臨時存在os cache，而未刷新到磁盤導致的消息丟失問題，那麼如何解決呢？
看過之前系列文章的小夥伴都知道，Broker是有兩種刷盤機制的，同步刷盤和異步刷盤，詳細內容可以回顧一下這篇文章：深入研究Broker是如何持久化的。
解決的方式就是把異步刷盤改爲同步刷盤，具體操作就是修改一下broker的配置文件，將其中的flushDiskType配置設置爲：SYNC_FLUSH，默認它的值是ASYNC_FLUSH，即異步刷盤。
調整爲同步刷盤後，只要MQ告訴我們消息發送成功了，那麼就說明消息已經在磁盤中了。
接下來就要解決磁盤壞了導致的消息丟失問題了。
這個問題其實也很好解決，只要我們使用RockerMQ的高可用集羣模式就可以了，也就是說如果返回消息發送成功的響應，那就代表Master Broker已經把數據同步到了Slave Broker中，保證數據有多個備份。
這樣一來就算是Master Broker突然宕機 ，也可以通過Dledger技術進行主從的自動切換，使用我們備份的數據，這其中的原理我們已經講過了，小夥伴們可以自己去複習回顧一下。Dledger是如何實現主從自動切換的
Consumer的消息丟失解決方案
到這裏，我們已經確保了生產者和Broker的消息不會丟失了，那麼消費者處理消息的時候會不會導致消息丟失呢？
答案是肯定的。
比如說我們的積分系統拿到了消息，還未執行該執行的操作，先返回給broker這條消息的offset，說這條消息已經處理過了。然後突然宕機了，這就導致mq認爲這條消息已經處理過了，而實際並沒有處理，所以這條消息就丟失掉了。
對於Kafka和RabbitMQ來講，默認的消費模式就是上邊這種自動提交的模式，所以是有可能導致消息丟失掉的。
而RocketMQ的消費者有點不一樣，它本身就是需要手動返回消息處理成功的響應的。
所以其實Consumer的消息丟失解決方案也很簡單，就是將自動提交改爲手動提交。
消息零丟失方案的優缺點分析
如果在系統中落地一套消息零丟失的方案，無論什麼場景都保證消息的可靠性，這似乎聽起來不錯，這也是它的優點所在，保證系統的數據都是正確的，不會有丟失的情況。
但它有什麼缺點呢？
首先，引入了這套解決方案之後，系統的複雜度變高了，想想事務消息的實現方式你肯定會這麼覺得。
而且比較嚴重的缺點是，它會導致系統的性能嚴重的下降，比如原來每秒可以處理好幾萬條的消息，結果在引入消息零丟失這套方案之後，可能每秒就只能處理幾千條消息了。
其實只要隨便思考一下，就可以想明白這個問題。
事務消息的複雜性導致生產消息的過程耗時更久了，同步刷盤的策略導致寫入磁盤後才返回消息，自然也會增加耗時，而消費者如果異步的處理消息，直接返回成功，整個流程的速度會更快。
所以說引入這麼一套消息零丟失的方案，對於性能的影響還是很大的。
總結
其實關於消息零丟失的方案無外乎就這麼多，所以本篇文章內容不是很多。
既然我們剛纔聊了消息零丟失方案的缺點，那麼就繼續討論一下，究竟什麼場景下需要引入這套方案吧。
王子給大家介紹一下自己的想法。
一般我們對於跟金錢、交易以及核心數據相關的系統和核心鏈路，可以採用這套方案。
比如說我們文章中舉的例子：支付系統、訂單系統、積分系統。
而對於其他的沒那麼核心的場景，丟失一些數據問題也不大，就不應該採用這套方案了，或者說可以做一些簡化，比如事務消息改成失敗重試幾次的機制，刷盤策略改爲異步刷盤。
那麼小夥伴們在平時的工作中，這套方案是怎麼應用到生產環境中的呢？歡迎留言討論。
往期文章推薦：
