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

目前為止，你的RabbitMQ部署在線上服務(wù)器了，對(duì)吧？然后訂單服務(wù)和倉(cāng)儲(chǔ)服務(wù)都可以基于RabbitMQ來(lái)收發(fā)消息，同時(shí)倉(cāng)儲(chǔ)服務(wù)宕機(jī)，不會(huì)導(dǎo)致消息丟失。

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

那如果此時(shí)出現(xiàn)一個(gè)問(wèn)題，就是說(shuō)訂單服務(wù)投遞了訂單消息到RabbitMQ里去，RabbitMQ暫時(shí)放在了自己的內(nèi)存中，還沒(méi)來(lái)得及投遞給下游的倉(cāng)儲(chǔ)服務(wù)呢，此時(shí)RabbitMQ突然宕機(jī)了，會(huì)怎么樣？

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

所以在這里而言，就牽扯到了RabbitMQ的一個(gè)較為重要的概念：消息的持久化，用英文來(lái)說(shuō)就是durable機(jī)制。

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

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

這樣，即使RabbitMQ宕機(jī)后重啟，也會(huì)恢復(fù)之前創(chuàng)建好的這個(gè)queue。

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

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

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

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

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

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

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

整個(gè)過(guò)程，如下圖所示：

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

因?yàn)橛锌赡躌abbitMQ接收到了消息，但是還沒(méi)來(lái)得及持久化到磁盤，他自己就宕機(jī)了，這個(gè)時(shí)候消息還是會(huì)丟失的。

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