RabbitMQ排他队列（exclusive queue）的适用场景说明

先给初学者提个醒，不用把这个特性想太复杂，你就把它当成和单个RabbitMQ连接强绑定的私人临时收件箱，官方定义的两个核心规则是硬限制，所有适用场景都是围绕这两个限制设计的：

1. 只有声明这个队列的连接，才能执行消费、清空、删除这类操作，其他连接完全没有操作权限
2. 只要声明它的连接断开（不管是正常关闭连接还是异常掉线），队列会被Broker直接自动删除，里面存的所有消息也会同步清理，不会留任何残留

实际开发里的高频适用场景主要有这几类：

• RPC/一对一请求响应的回调队列
  这是排他队列最经典的使用场景。客户端发RPC请求到服务端的公共工作队列时，会先声明一个排他队列，把队列名写到消息的reply-to属性里；服务端处理完请求，直接把响应结果发到这个回调队列就行。因为这个队列只有发起请求的客户端连接能消费，完全不会出现响应被别的客户端抢走的问题；而且如果客户端中途掉线，队列会自动删掉，不会堆积一堆没人收的无效响应占用存储资源。
• 单用户/单客户端的临时实时消息推送
  做网页端浮层通知、操作进度条实时推送、协同编辑状态同步这类不需要持久化的实时场景时，每个客户端连上RabbitMQ之后单独声明一个排他队列，绑定到对应的topic或者fanout交换器，只收和自己相关的临时消息就行。这类场景本身就不要求消息留痕，客户端掉线重连后本来就要重新同步最新状态，旧队列自动删除的特性刚好省掉手动清理掉线用户残留队列的逻辑，也不会出现僵尸队列长期占资源的问题。
• 单应用连接内的轻量任务流转
  如果你的单个应用服务内部需要做协程/线程间的临时任务分发，又不想用本地内存队列（想复用RabbitMQ自带的消息确认、失败重试、死信转发这些能力），就可以用排他队列。这个队列只有当前服务的连接能操作，其他服务完全访问不到，不会出现消息被别的服务误消费的问题；服务下线的时候连接断开，队列自动清理，也不会残留没处理完的临时脏任务。

最后给新手提几个实际踩过的避坑点：

这些场景绝对不要用排他队列：

• 不要存储需要持久化的核心业务消息，连接一断消息全丢，没有任何恢复的可能
• 不要做多服务/多消费者共享的业务队列，其他连接根本没有操作权限，调用会直接报错
• 不要试图把排他队列当长期队列用，哪怕你声明的时候加了持久化参数，连接断开时它还是会被强制删除，持久化参数对排他队列不生效

内容的提问来源于stack exchange，提问作者Timothy C. Quinn