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

為什么在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消息持久化異常,提高消息推送效率。

? 版權(quán)聲明
THE END
喜歡就支持一下吧
點(diǎn)贊10 分享