Queues

Names

Queues 有名字，这样应用才能引用它们。
应用可能自己取名或者让broker为它生活吃呢过一个名字。Queue名字最多可包含255个字节的UTF-8字符。
以“amq.”开头的queue名字是broker内部预留的。试图违反规则声明一个这样名字的queue 会导致一个channel级的异常，返回码为403（ACCESS_REFUSED）

Server-named Queues

在AMQP 0-9-1中，broker可以代表应用生成唯一的队列名称。要使用此功能，请将空字符串作为队列名称参数传递：通过使用需要队列名称的空字符串，可以通过同一通道中的后续方法获取相同的生成名称。这是有效的，因为channel会记住上次服务器生成的队列名称。

Properties

queue拥有定义它的行为的属性值。下面是一组必要属性和一个可选择的map：
Name
Durable（queue将在broker重启后继续存在）
Exclusive（仅由一个连接使用，并且该连接关闭时将删除队列）
Auto-delete（当最后一个consumer取消订阅时，至少有一个consumer的queue被删除）
Arguments（可选的，由插件和特定与broker的功能使用，例如消息TTL，队列长度限制等）

Declaration and Property Equivalence

在一个队列可以使用之前，必须声明它。声明队列将导致它创建（如果它不存在）。如果队列已经存在并且其属性与声明中的属性相同，则声明将不起作用。如果现有队列属性与声明中队列属性不同时，将引发具有代码406（PRECONDITION_FAILED）的channel级异常。

Optional Arguments

可选的queue参数，也称为"x-arguments"。因为它们在AMQP 0-9-1协议中的字段名称是一个map（字典），可以在声明队列时由客户端提供。它们由插件和特定于broker的功能使用，例如

• Message and queue TTL
• Queue length limit
• Mirroring settings
• Max number of priorities
• Consumer priorities
  等等。

可选参数可以通过两种方式提供：
使用策略的队列组（推荐）
当客户端声明一个queue时，以每个队列为基础（On a per-queue basis when a queue is declared by a client，水平有限，不会翻译。。。）

前一种选择更灵活，非侵入性，不需要修改和重新部署应用程序。因此，强烈建议大多数用户使用。

客户端提供可选参数的方式因client library到client library而异，但通常是在durable，auto_delete和声明queue的函数的其他参数之后的下一个参数。

Message Ordering

RabbitMQ中的队列是有序的消息集合。message以FIFO方式入队出队，尽管优先级队列，分片队列和其他功能可能会影响这种方式。

Durability

持久化队列持久化到磁盘中，因此可以在broker重启后继续运行。不持久的队列称为瞬态。并非所有场景和用例都要求队列持久。
队列的持久性不会使路由到该队列的message持久。如果broker被删除后重新启动，则在代理启动期间将重新声明持久队列，但是只会恢复持久性message。

Temporary Queues

对于一些工作负载，队列应该是短暂的。虽然客户端可以在断开连接之前删除它们声明的队列，但这并不总是很方便。最重要的是，客户端连接可能会失败，可能会留下未使用的资源（队列）。

有三种方式可以自动删除队列：
Exclusive queues
TTLs
Auto-delete queues

当其最后一个消费者被取消时（如，使用AMQP 0-9-1中的basic.cancel）或者已经消失（关闭的通道或连接，或者于server的TCP连接丢失），将自动删除队列。

如果队列从未有任何消费者，如，当使用basic.get方法（“Pull” API）发生所有消费时，它将不会自动删除。对于这种情况，请使用exclusive queue或者 queue TTL

Exclusive Queues

exclusive queue只能通过其声明连接来使用（消耗，清洗，删除等）。尝试使用来自不同连接的exclusive queue将导致通道级异常RESOURCE_LOCKED，并显示一条错误消息：cannot obtain exclusive access to locked queue.

当其声明连接关闭或消失时（如，由于底层TCP连接丢失），将删除exclusive queue。因此，它们仅适用于client特定的瞬态。
通常使用服务器命名的exclusive queue。

Mirrored and Distributed Queues

队列可以跨集群节点进行复制，并通过松散耦合的节点或集群进行联合。请注意，镜像和联合是正交特征，不应视为直接替代。

Time-to-Live and Length Limit

Queue可以拥有长度限制。Queue和message也可以拥有TTL（time to live）。
这两个功能都可以用于数据到期，并且可以限制队列最多可以使用多少资源（RAM，磁盘空间），例如：当consumer离线或其吞吐量落后于publisher时。

In Memory and Durable Storage

队列将消息保存在RAM和/或磁盘上。在一些协议（例如AMQP 0-9-1）中，这由客户端部分地控制。在AMQP 0-9-1中，这是通过消息属性（delivery_mode，或在某些客户端，persistent）完成的。
将消息发布为瞬态表明RabbitMQ应该在RAM中保留尽可能多的消息。但是，当队列发现自己处于内存压力之下时，队列甚至会将瞬态消息写入磁盘。
路由到持久队列的持久消息将分批或者在经过一定时间后（几分之一秒）保留。
无论持久性属性如何，Lazy queue都会将消息更积极地输出到磁盘

Priorities

queue可以拥有0个或更多优先级。此功能是选择性加入：只通过可选参数配置的具有最大优先级的队列才会优先。
publisher使用消息属性中的priority 字段指定message优先级。
如果需要优先级队列，我们建议使用1到10之间。目前使用更多优先级将消耗更多资源（Erlang 进程）。

CPU Utilisation and Parallelism Considerations

目前，单个队列（主服务器或镜像服务器）仅限于其热代码路径上的单个CPU核心。因此，该设计假设大多数系统在实践中使用多个队列。单个队列通常被认为是反模式的（并且不仅仅是出于资源利用的原因）。
如果需要权衡消息排序的并行性（更好的CPU核心利用率），rabbitmq-sharding 提供了一种对client透明的方式。

Metrics and Monitoring

RabbitMQ收集有关队列的多个指标。其中大多数都可以通过RabbitMQ HTTP API和管理UI获得，它是专为监控而设计的。这包括队列长度，入口和出口速率，消费者数量，各种状态下的消息数量（例如准备交付或未确认），RAM中与磁盘上的消息数量等等。
可以使用管理UI中的rabbitmq-top插件和单个队列页面来访问运行时指标，例如VM调度程序使用，队列（Erlang）进程GC活动，队列进程使用的RAM量，队列进程邮箱长度。

Consumers and Acknowledgments

可以通过注册使用者（订阅）来消费消息，这意味着RabbitMQ将消息推送到客户端，或者单独获取支持此消息的协议（例如basic.get AMQP 0-9-1方法），类似于HTTP GET。
一旦将传递写入连接套接字，消费者就可以明确地或自动地确认传递的消息。
自动确认模式通常会提供更高的吞吐量和更少的网络带宽。然而，当遇到失败时，它提供的保证最少。根据经验，首先考虑使用手动确认模式。

Prefetch and Consumer Overload

自动确认模式也可以压倒消费者，消费者无法在交付消息时尽快处理消息。这可能导致消费者进程的内存使用和/或OS切换的永久性增长。
手动确认模式提供了一种设置未完成（未确认）交付数量限制的方法：信道QoS（预取）。
使用更高（数千或更多）预取级别的消费者可能会遇到与使用自动确认的消费者相同的过载问题。
大量未确认的消息将导致代理更高的内存使用量。

Message States

入队消息通常处于两种状态之一：
准备交付
已交付但还未被consumer确认

Determining Queue Length

可以通过多种方式确定队列长度：
使用AMQP 0-9-1，在queue.declare方法响应（queue.declare-ok）上使用属性。字段名称为message_count。访问方式因客户端库到客户端库而异。
使用RabbitMQ HTTP API。
使用rabbitmqctl list_queues命令。

队列长度定义为准备传递的消息数。

文章：http://www.rabbitmq.com/queues.html