?這篇文章，給不太熟悉MQ技術(shù)的同學，介紹一個生產(chǎn)環(huán)境中可能會遇到的問題。

目前為止，你的RabbitMQ部署在線上服務器了，對吧？然后訂單服務和倉儲服務都可以基于RabbitMQ來收發(fā)消息，同時倉儲服務宕機，不會導致消息丟失。

好，我們來看下目前為止的架構(gòu)圖。

那如果此時出現(xiàn)一個問題，就是說訂單服務投遞了訂單消息到RabbitMQ里去，RabbitMQ暫時放在了自己的內(nèi)存中，還沒來得及投遞給下游的倉儲服務呢，此時RabbitMQ突然宕機了，會怎么樣？

答案其實很簡單，默認情況下，按照我們目前的代碼和配置，這個數(shù)據(jù)就會丟失了。

所以在這里而言，就牽扯到了RabbitMQ的一個較為重要的概念：消息的持久化，用英文來說就是durable機制。

然后這里又有一個引申的概念，如果按照我們之前的代碼和配置，默認情況下，RabbitMQ一旦宕機就再次重啟，就會丟失我們之前創(chuàng)建的queue。所以首先得先讓queue是持久化的。

使用下面的代碼，就可以把我們的“warehouse_schedule_delivery”這個queue，也就是倉儲調(diào)度發(fā)貨的queue，設置為持久化的。

這樣，即使RabbitMQ宕機后重啟，也會恢復之前創(chuàng)建好的這個queue。

大家看到上面那行定義和創(chuàng)建queue的代碼么？核心在于第二個參數(shù)，第二個參數(shù)是true。

他的意思就是說，這個創(chuàng)建的queue是durable的，也就是支持持久化的。

RabbitMQ會把這queue的相關(guān)信息持久化的存儲到磁盤上去，這樣RabbitMQ重啟后，就可以恢復持久化的queue。

OK，現(xiàn)在你的queue的信息可以持久化了，RabbitMQ宕機重啟后會自動恢復queue。但是，你的queue里的message數(shù)據(jù)呢？ queue里都是訂單服務發(fā)送過去的訂單消息數(shù)據(jù)，如果RabbitMQ還沒來得及投遞queue里的訂單消息到倉儲服務，結(jié)果RabbitMQ就宕機了。

那此時RabbitMQ重啟之后，他可以恢復queue的信息，但是queue的message數(shù)據(jù)是沒法恢復了。 所以此時還有一個重要的點，就是在你的訂單服務發(fā)送消息到RabbitMQ的時候，需要定義這條消息也是durable，即持久化的。

通過上面的方式來發(fā)送消息，就可以讓發(fā)送出去的消息是持久化的。

一旦標記了消息是持久化之后，就會讓RabbitMQ把消息持久化寫入到磁盤上去，此時如果RabbitMQ還沒投遞數(shù)據(jù)到倉儲服務，結(jié)果就突然宕機了。那么再次重啟的時候，就會把磁盤上持久化的消息給加載出來。

整個過程，如下圖所示：

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

因為有可能RabbitMQ接收到了消息，但是還沒來得及持久化到磁盤，他自己就宕機了，這個時候消息還是會丟失的。

如果要完全100%保證寫入RabbitMQ的數(shù)據(jù)必須落地磁盤，不會丟失，需要依靠其他的機制。?