【Java進階面試系列之五】消息中間件集羣崩潰，如何保證百萬生產數據不丟失？【石杉的架構筆記】

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）

週一至週五早8點半！精品技術文章準時送上！

「上一篇講消息中間件的文章《扎心！線上服務宕機時，如何保證數據100%不丟失？》，初步給你們介紹了一個在生產環境中可能遇到的問題，就是你的消費者服務可能會宕機，一旦宕機，你就須要考慮是否會致使沒處理完的消息丟失。這篇文章，再給不太熟悉MQ技術的同窗，介紹另一個生產環境中可能會遇到的問題。

目前爲止，你的RabbitMQ部署在線上服務器了，對吧？而後訂單服務和倉儲服務均可以基於RabbitMQ來收發消息，同時倉儲服務宕機，不會致使消息丟失。

好，咱們來看下目前爲止的架構圖。

那若是此時出現一個問題，就是說訂單服務投遞了訂單消息到RabbitMQ裏去，RabbitMQ暫時放在了本身的內存中，還沒來得及投遞給下游的倉儲服務呢，此時RabbitMQ忽然宕機了，會怎麼樣？

答案其實很簡單，默認狀況下，按照咱們目前的代碼和配置，這個數據就會丟失了。

因此在這裏而言，就牽扯到了RabbitMQ的一個較爲重要的概念：消息的持久化，用英文來講就是durable機制。

而後這裏又有一個引伸的概念，若是按照咱們以前的代碼和配置，默認狀況下，RabbitMQ一旦宕機就再次重啓，就會丟失咱們以前建立的queue。因此首先得先讓queue是持久化的。

使用下面的代碼，就能夠把咱們的「warehouse_schedule_delivery」這個queue，也就是倉儲調度發貨的queue，設置爲持久化的。

這樣，即便RabbitMQ宕機後重啓，也會恢復以前建立好的這個queue。

channel.queueDeclare(
       "warehouse_schedule_delivery",
        true, 
        false,
        false,
        null);
複製代碼

你們看到上面那行定義和建立queue的代碼麼？核心在於第二個參數，第二個參數是true。

他的意思就是說，這個建立的queue是durable的，也就是支持持久化的。

RabbitMQ會把這queue的相關信息持久化的存儲到磁盤上去，這樣RabbitMQ重啓後，就能夠恢復持久化的queue。

OK，如今你的queue的信息能夠持久化了，RabbitMQ宕機重啓後會自動恢復queue。可是，你的queue裏的message數據呢？

queue裏都是訂單服務發送過去的訂單消息數據，若是RabbitMQ還沒來得及投遞queue裏的訂單消息到倉儲服務，結果RabbitMQ就宕機了。

那此時RabbitMQ重啓以後，他能夠恢復queue的信息，可是queue的message數據是無法恢復了。

因此此時還有一個重要的點，就是在你的訂單服務發送消息到RabbitMQ的時候，須要定義這條消息也是durable，即持久化的。

channel.basicPublish(
 "", 
 "warehouse_schedule_delivery",
 MessageProperties.PERSISTENT_TEXT_PLAIN,
 message.getBytes());

複製代碼

經過上面的方式來發送消息，就可讓發送出去的消息是持久化的。

一旦標記了消息是持久化以後，就會讓RabbitMQ把消息持久化寫入到磁盤上去，此時若是RabbitMQ還沒投遞數據到倉儲服務，結果就忽然宕機了。那麼再次重啓的時候，就會把磁盤上持久化的消息給加載出來。

整個過程，以下圖所示：

可是這裏要注意一點，RabbitMQ的消息持久化，是不承諾100%的消息不丟失的。

由於有可能RabbitMQ接收到了消息，可是還沒來得及持久化到磁盤，他本身就宕機了，這個時候消息仍是會丟失的。

若是要徹底100%保證寫入RabbitMQ的數據必須落地磁盤，不會丟失，須要依靠其餘的機制。

下次有機會再繼續給不太熟悉MQ技術的同窗，來說解這裏的東西。

END

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授

推薦閱讀：

一、拜託！面試請不要再問我Spring Cloud底層原理

二、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？

三、【性能優化之道】每秒上萬併發下的Spring Cloud參數優化實戰

四、微服務架構如何保障雙11狂歡下的99.99%高可用

五、兄弟，用大白話告訴你小白都能聽懂的Hadoop架構原理

六、大規模集羣下Hadoop NameNode如何承載每秒上千次的高併發訪問

七、【性能優化的祕密】Hadoop如何將TB級大文件的上傳性能優化上百倍

八、拜託，面試請不要再問我TCC分佈式事務的實現原理坑爹呀！

九、【坑爹呀！】最終一致性分佈式事務如何保障實際生產中99.99%高可用？

十、拜託，面試請不要再問我Redis分佈式鎖的實現原理！

十一、【眼前一亮！】看Hadoop底層算法如何優雅的將大規模集羣性能提高10倍以上？

十二、億級流量系統架構之如何支撐百億級數據的存儲與計算

1三、億級流量系統架構之如何設計高容錯分佈式計算系統

1四、億級流量系統架構之如何設計承載百億流量的高性能架構

1五、億級流量系統架構之如何設計每秒十萬查詢的高併發架構

1六、億級流量系統架構之如何設計全鏈路99.99%高可用架構

1七、七張圖完全講清楚ZooKeeper分佈式鎖的實現原理

1八、大白話聊聊Java併發面試問題之volatile究竟是什麼？

1九、大白話聊聊Java併發面試問題之Java 8如何優化CAS性能？

20、大白話聊聊Java併發面試問題之談談你對AQS的理解？

2一、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？

2二、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化

2三、互聯網公司的面試官是如何360°無死角考察候選人的？（上篇）

2四、互聯網公司面試官是如何360°無死角考察候選人的？（下篇）

2五、Java進階面試系列之一：哥們，大家的系統架構中爲何要引入消息中間件？

2六、【Java進階面試系列之二】：哥們，那你說說系統架構引入消息中間件有什麼缺點？

2七、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷

2八、【Java進階面試系列之三】哥們，消息中間件在大家項目裏是如何落地的？

2九、【Java進階面試系列之四】扎心！線上服務宕機時，如何保證數據100%不丟失？

30、一次JVM FullGC的背後，竟隱藏着驚心動魄的線上生產事故！

3一、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？

做者：石杉的架構筆記 連接：https://juejin.im/post/5c1c8f5a6fb9a049fe351f36 來源：掘金 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。