RbbitMq不推荐使用匿名队列_rabbitmq 匿名队列-优快云博客

本文链接：https://blog.youkuaiyun.com/zjcjava/article/details/121852117

博客讲述了在生产环境中遇到的一个问题，由于原先负责人员离职，导致K8s集群中出现持续的磁盘预警，问题源头是一个排它队列。由于队列的排它性质，无法直接在外部解绑，且队列名称为匿名生成，无法直接在代码中定位。作者尝试通过MQ控制面板操作，但因权限问题失败。最终发现队列由Spring Boot配置的匿名队列引起，建议避免在生产中使用匿名队列以提高问题排查效率。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

问题描述

生产中的项目原来的人都不在了，但是生产中k8s的预警异常消息不停的发送磁盘超出预警范围，并爆出了此队列的名称，但是无论如何在本地代码中没有找到这个队列，只能根据队列在MQ控制面板中找到关联的exchange，大大影响了问题处理的速度。
尝试本地链接生产解绑该队列，但是尝试失败，爆出了链接异常：reply-code=405, reply-text=RESOURCE_LOCKED

排它队列

在这里插入图片描述

exclusive：是否排外的，有两个作用，
一：当连接关闭时connection.close()该队列是否会自动删除；二：该队列是否是私有的private，如果不是排外的，可以使用两个消费者都访问同一个队列，没有任何问题，如果是排外的，会对当前队列加锁，其他通道channel是不能访问的，如果强制访问会报异常（reply-code=405, reply-text=RESOURCE_LOCKED）。

spring.gen队列的由来

排查过程中，无法链接到这个MQ服务队列，因为是排它的这样当磁盘空间达到预警值时，你无法从外部将它解绑。甚至你无法根据这个队列名去找源码，因为它是随机生成的，业务代码中没有显式的名称。
只能根据交换机名称去查找，这里我很久没找到是因为我本地的是最新的源码，这个地方已经在几个月前被其他同事改为了显式的非匿名队列，因此建议项目中不要使用匿名队列。

 @Bean
  public Queue iotDeviceStatusQueue() {
    return new AnonymousQueue();
  }