RabbitMQ中，即使设置delivery_mode: 1（即非持久化），消息默认仍可能被写入磁盘，原因如下：1. 消息的持久化机制delivery_mode

RabbitMQ消息持久化异常：delivery_mode: 1失效分析

本文探讨RabbitMQ中一个令人困惑的问题：即使将delivery_mode设置为1（非持久化），消息仍然写入磁盘。此现象导致消息推送速度缓慢，监控面板显示内存和持久化消息数量一致。

在标准RabbitMQ配置中，delivery_mode: 1表示消息非持久化，不应写入磁盘；delivery_mode: 2表示持久化，写入磁盘。然而，用户在一个Kubernetes集群中部署的RabbitMQ实例(版本rabbitmq:3.8-management)中观察到此异常，而在Docker环境中则未出现此问题。

初步怀疑是RabbitMQ服务器内存不足或某些特性启用所致。然而，进一步调查发现，无论delivery_mode设置为1或2，监控面板数据均显示内存和持久化消息数量相同，这排除了简单的内存不足问题。

关键突破在于队列类型。经分析，Stream队列的默认行为是将消息持久化到磁盘，以保证消息可靠性和顺序性，这解释了即使delivery_mode: 1，消息仍然持久化的现象。

因此，Kubernetes集群中的RabbitMQ实例可能默认使用了Stream队列，导致了该问题。 Docker环境中未出现此问题，可能源于配置或默认设置的差异。

解决方法：

为了解决此问题，用户需要：

1. 验证队列类型: 检查Kubernetes集群中RabbitMQ实例使用的队列类型。如果是Stream队列，则需要切换到其他队列类型，例如classic队列。

2. 修改队列配置: 如果无法更改队列类型，则需要与Kubernetes管理员协商，修改RabbitMQ的配置文件，以调整Stream队列的持久化设置。

3. 环境差异分析: 深入对比Docker和Kubernetes环境下的RabbitMQ配置，找出导致差异的关键设置。

通过以上步骤，可以有效解决RabbitMQ消息持久化异常，提高消息推送效率。