本篇围绕 RabbitMQ 中最基本的 fabric – queue 进行讨论，主要介绍其常用的几个属性设置，以及在实际使用中的约束条件。

常用queue属性

在 rabbitmq-c代码中可以看到如下代码

上图所示为queue声明时使用的结构体。其中最容易让使用者迷惑的3个属性是durable、exclusive和auto_delete。

上图所示为consumer从queue进行消息消费时用于设置属性的结构体。其中最容易让使用者迷惑的属性是exclusive（上图中的exclusive注释有点问题，请忽略）。

测试过程

在编写python语言的测试程序时，我将行为分为以下几步

• 声明7个具有不同属性的queue，分别和名为test_exchage的exchange进行绑定（因为exchange为fanout类型，所以测试代码中的routing_key其实是不起作用的）；
• 向exchange发送具有persistent属性的消息（delivery_mode=2）；
• 创建7个消费者分别从上述7个queue中获取消息；

测试结果如下

可以看到，所有的7个消费者均收到了对应的消息内容。 

下面我们从RabbitMQ服务器测查看以下上述测试能展现什么信息。

1.client和server建立了一条AMQP connection。

2.在该connection上使用了channel号1进程AMQP协议通信。

3.连接建立时的用户名为guest，以及各种channel属性设置情况。

4.在当前channel上共存在7个消费者，分别从7个不同的queue上获取消息；该channel上的消息均来自名为test_exchage的exchange（请原谅我测试过程中的英文拼写错误）。

从Exchanges选项卡上可以看到test_exchage下绑定了哪些queue。

从Queues选项卡上可以看到全部7个queue的属性情况

看到这里，眼尖的同学可能会发现问题所在了，那就是客户端代码中声明的queue属性并没有全部生效，为什么会这样呢？

首先分别看一下代码中声明的7个queue在服务器侧的详细信息。

a.test_1_queue没有设置任何属性，在界面上没有看到任何属性。

b. test_2_queue设置了durable属性，在界面上看到了“durable:true”。

 

c. test_3_queue设置了auto-delete属性，在界面上看到了“auto-delete:true”。

d. test_4_queue同时设置了durable和auto-delete属性，在界面上看到了“durable:true和auto-delete:true”。

e. test_5_queue同时设置了durable和exclusive属性,但在界面上只看到了“Exlusive owner”的存在。

f. test_6_queue同时设置了auto_delete和exclusive属性，在界面上同时看到“auto-delete:true”和“Exlusive owner”的存在。

g. test_7_queue同时设置了durable、auto_delete和exclusive属性,在界面上只看到了“auto-delete:true”和“Exlusive owner”的存在。

综上，可以得出如下结论

• durable属性和auto-delete属性可以同时生效；
• durable属性和exclusive属性会有性质上的冲突，两者同时设置时，仅exclusive属性生效；
• auto_delete属性和exclusive属性可以同时生效；

除此之外，还能得到其它一些有趣的结论：

• Queue的“Exlusive owner”对应的是connection而不是channel；
• Consumer存在于某个channel上的；

 附上一张客户端同时设置durable、auto_delete和exclusive属性的抓包截图：

下面通过改变client侧代码，模拟不同情况下各种属性对queue的存在情况的影响。

a.在成功创建全部7个queue后，通过Ctrl+C异常终止客户端程序。

（上图为全部创建时的状态）

 

 停止后，queue的情况如下图所示。

对比发现，此时只有 test_1_queue 和 test_2_queue 仍旧存在，其它queue已经被RabbitMQ服务器删除掉了（思考原因）。

b.客户端侧执行到消息发送后，结束当前操作（无consumer情况）。代码调整如下

此时仍旧可以看到queue的声明和绑定都是成功的。

此时客户端程序执行后会自动退出

再从web页面查看queue的情况如下

对比发现，此时仅test_1_queue、test_2_queue、test_3_queue和test_4_queue 存在（思考原因）。

      这里有个细节值得说一下：虽然最终我们在web页面上只看到了4个queue的存在，但其实7个queue都被成功创建过（抓包可以证明），如果你够幸运，你也可能在web页面上看到一闪而过的另外3个queue。通过对比可以发现，导致另外3个queue消失的原因是exclusive属性的设置，前面我已经说过，queue的“Exlusive owner”对应的是connection，所以在这个实验中可以确定的是，connection仍旧是存在的（这里遗留个问题：为什么python执行退出后连接仍旧存在），而此时实际上不存在的是consumer，所以需要对之前得到的结论进行加强：具有exclusive属性的queue的存在条件是在connection上存在某个consumer订阅了该queue。同样可以得到另外一个结论：可以在没有创建consumer的情况下，创建出具有auto-delete属性的queue。

在RabbitMQ官方文档中其实已经对上述现象进行了说明，只不过一语带过，不注意的话容易忽略掉。在queue.declare方法中包含如下属性说明

此时肯定有人会问，除了queue.declare中具有exclusive属性，basic.consume中也具有exclusive属性，后者是什么含义呢？在文档说明中有如下内容

由此可以理解两个属性的差异和实际使用中应该注意的问题是什么！（自行思考）

在此情况下，若执行RabbitMQ server的重启（rabbitmqctl stop_app;rabbitmqctl start_app），可以看到仅有test_2_queue和test_4_queue仍旧存在。

测试版本

以上测试基于如下RabbitMQ版本

为什么使用这个版本？（我猜肯定有人会问）因为这个实验是我半年前就已经完成了的~~

来自：http://my.oschina.net/moooofly/blog/392239