為什么在RabbitMQ中即使設(shè)置了delivery_mode: 1，消息依舊被寫入磁盤？

rabbitmq消息持久化異常：delivery_mode: 1失效分析

本文探討RabbitMQ中一個(gè)令人困惑的問題：即使將delivery_mode設(shè)置為1（非持久化），消息仍然寫入磁盤。此現(xiàn)象導(dǎo)致消息推送速度緩慢，監(jiān)控面板顯示內(nèi)存和持久化消息數(shù)量一致。

在標(biāo)準(zhǔn)RabbitMQ配置中，delivery_mode: 1表示消息非持久化，不應(yīng)寫入磁盤；delivery_mode: 2表示持久化，寫入磁盤。然而，用戶在一個(gè)kubernetes集群中部署的RabbitMQ實(shí)例(版本rabbitmq:3.8-management)中觀察到此異常，而在docker環(huán)境中則未出現(xiàn)此問題。

初步懷疑是RabbitMQ服務(wù)器內(nèi)存不足或某些特性啟用所致。然而，進(jìn)一步調(diào)查發(fā)現(xiàn)，無論delivery_mode設(shè)置為1或2，監(jiān)控面板數(shù)據(jù)均顯示內(nèi)存和持久化消息數(shù)量相同，這排除了簡(jiǎn)單的內(nèi)存不足問題。

關(guān)鍵突破在于隊(duì)列類型。經(jīng)分析，Stream隊(duì)列的默認(rèn)行為是將消息持久化到磁盤，以保證消息可靠性和順序性，這解釋了即使delivery_mode: 1，消息仍然持久化的現(xiàn)象。

因此，Kubernetes集群中的RabbitMQ實(shí)例可能默認(rèn)使用了Stream隊(duì)列，導(dǎo)致了該問題。 Docker環(huán)境中未出現(xiàn)此問題，可能源于配置或默認(rèn)設(shè)置的差異。

解決方法：

為了解決此問題，用戶需要：

1. 驗(yàn)證隊(duì)列類型: 檢查Kubernetes集群中RabbitMQ實(shí)例使用的隊(duì)列類型。如果是Stream隊(duì)列，則需要切換到其他隊(duì)列類型，例如classic隊(duì)列。

2. 修改隊(duì)列配置: 如果無法更改隊(duì)列類型，則需要與Kubernetes管理員協(xié)商，修改RabbitMQ的配置文件，以調(diào)整Stream隊(duì)列的持久化設(shè)置。

3. 環(huán)境差異分析: 深入對(duì)比Docker和Kubernetes環(huán)境下的RabbitMQ配置，找出導(dǎo)致差異的關(guān)鍵設(shè)置。

通過以上步驟，可以有效解決RabbitMQ消息持久化異常，提高消息推送效率。