1. 概念

如何保障當(dāng) RabbitMQ 服務(wù)停掉以后消息生產(chǎn)者發(fā)送過來的消息不丟失。默認(rèn)情況下 RabbitMQ 退出或由于某種原因崩潰時(shí)，它忽視隊(duì)列和消息，除非告知它不要這樣做。確保消息不會(huì)丟失需要做兩件事： 我們需要將隊(duì)列和消息都標(biāo)記為持久化。

2. 隊(duì)列如何實(shí)現(xiàn)持久化

之前我們創(chuàng)建的隊(duì)列都是非持久化的， rabbitmq 如果重啟的化，該隊(duì)列就會(huì)被刪除掉，如果要隊(duì)列實(shí)現(xiàn)持久化需要在聲明隊(duì)列的時(shí)候把 durable 參數(shù)設(shè)置為持久化

但是需要注意的就是如果之前聲明的隊(duì)列不是持久化的，需要把原先隊(duì)列先刪除，或者重新創(chuàng)建一個(gè)持久化的隊(duì)列，不然就會(huì)出現(xiàn)錯(cuò)誤。

以下為控制臺(tái)中持久化與非持久化隊(duì)列的 UI 顯示區(qū)：

這個(gè)時(shí)候即使重啟 rabbitmq 隊(duì)列也依然存在。

3. 消息實(shí)現(xiàn)持久化

要想讓消息實(shí)現(xiàn)持久化需要在消息生產(chǎn)者修改代碼， MessageProperties.PERSISTENT_TEXT_PLAIN 添加這個(gè)屬性。

將消息標(biāo)記為持久化并不能完全保證不會(huì)丟失消息。盡管它告訴 RabbitMQ 將消息保存到磁盤，但是這里依然存在當(dāng)消息剛準(zhǔn)備存儲(chǔ)在磁盤的時(shí)候但是還沒有存儲(chǔ)完，消息還在緩存的一個(gè)間隔點(diǎn)。此時(shí)并沒有真正寫入磁盤。持久性保證并不強(qiáng)，但是對(duì)于我們的簡單任務(wù)隊(duì)列而言，這已經(jīng)綽綽有余了。如果需要更強(qiáng)有力的持久化策略，可通過發(fā)布確認(rèn)方式實(shí)現(xiàn)。

4. 不公平分發(fā)

在最開始的時(shí)候我們學(xué)習(xí)到 RabbitMQ 分發(fā)消息采用的輪訓(xùn)分發(fā)，但是在某種場(chǎng)景下這種策略并不是很好，比方說有兩個(gè)消費(fèi)者在處理任務(wù)，其中有個(gè)消費(fèi)者 1 處理任務(wù)的速度非常快，而另外一個(gè)消費(fèi)者 2處理速度卻很慢，這個(gè)時(shí)候我們還是采用輪訓(xùn)分發(fā)的化就會(huì)到這處理速度快的這個(gè)消費(fèi)者很大一部分時(shí)間處于空閑狀態(tài)，而處理慢的那個(gè)消費(fèi)者一直在干活，這種分配方式在這種情況下其實(shí)就不太好，但是RabbitMQ 并不知道這種情況它依然很公平的進(jìn)行分發(fā)。

為了避免這種情況，我們可以設(shè)置參數(shù) channel.basicQos(1);

意思就是如果這個(gè)任務(wù)我還沒有處理完或者我還沒有應(yīng)答你，你先別分配給我，我目前只能處理一個(gè)任務(wù)，然后 rabbitmq 就會(huì)把該任務(wù)分配給沒有那么忙的那個(gè)空閑消費(fèi)者，當(dāng)然如果所有的消費(fèi)者都沒有完成手上任務(wù)，隊(duì)列還在不停的添加新任務(wù)，隊(duì)列有可能就會(huì)遇到隊(duì)列被撐滿的情況，這個(gè)時(shí)候就只能添加新的 worker 或者改變其他存儲(chǔ)任務(wù)的策略。

5. 預(yù)取值

本身消息的發(fā)送就是異步發(fā)送的，所以在任何時(shí)候， channel 上肯定不止只有一個(gè)消息另外來自消費(fèi)者的，手動(dòng)確認(rèn)本質(zhì)上也是異步的。因此這里就存在一個(gè)未確認(rèn)的消息緩沖區(qū)，因此希望開發(fā)人員能限制此緩沖區(qū)的大小，以避免緩沖區(qū)里面無限制的未確認(rèn)消息問題。

這個(gè)時(shí)候就可以通過使用 basic.qos 方法設(shè)置“預(yù)取計(jì)數(shù)” 值來完成的。 該值定義通道上允許的未確認(rèn)消息的最大數(shù)量。一旦數(shù)量達(dá)到配置的數(shù)量，RabbitMQ 將停止在通道上傳遞更多消息，除非至少有一個(gè)未處理的消息被確認(rèn)，例如，假設(shè)在通道上有未確認(rèn)的消息 5、 6、 7， 8，并且通道的預(yù)取計(jì)數(shù)設(shè)置為 4，此時(shí)RabbitMQ 將不會(huì)在該通道上再傳遞任何消息，除非至少有一個(gè)未應(yīng)答的消息被 ack。比方說 tag=6 這個(gè)消息剛剛被確認(rèn) ACK， RabbitMQ 將會(huì)感知到這個(gè)情況并再發(fā)送一條消息。

消息應(yīng)答和 QoS 預(yù)取值對(duì)用戶吞吐量有重大影響。通常，增加預(yù)取將提高向消費(fèi)者傳遞消息的速度。 雖然自動(dòng)應(yīng)答傳輸消息速率是最佳的，但是，在這種情況下已傳遞但尚未處理的消息的數(shù)量也會(huì)增加，從而增加了消費(fèi)者的 RAM 消耗(隨機(jī)存取存儲(chǔ)器)應(yīng)該小心使用具有無限預(yù)處理的自動(dòng)確認(rèn)模式或手動(dòng)確認(rèn)模式，消費(fèi)者消費(fèi)了大量的消息如果沒有確認(rèn)的話，會(huì)導(dǎo)致消費(fèi)者連接節(jié)點(diǎn)的內(nèi)存消耗變大，所以找到合適的預(yù)取值是一個(gè)反復(fù)試驗(yàn)的過程，不同的負(fù)載該值取值也不同 100 到 300 范圍內(nèi)的值通?？商峁┳罴训耐掏铝?，并且不會(huì)給消費(fèi)者帶來太大的風(fēng)險(xiǎn)。預(yù)取值為 1 是最保守的。當(dāng)然這將使吞吐量變得很低，特別是消費(fèi)者連接延遲很嚴(yán)重的情況下，特別是在消費(fèi)者連接等待時(shí)間較長的環(huán)境中。對(duì)于大多數(shù)應(yīng)用來說，稍微高一點(diǎn)的值將是最佳的。