以"amq."开头的队列是由消息中间件代理内部生成的，有其特殊的作用，因此不能声明此类名称的新队列，否则会导致通道级别的异常，异常代码为403(ACCESS_REFUSED)。
队列的持久化特性持久化的队列会持久化到磁盘中，这种队列在消息中间件代理重启后不会被删除。不开启持久化特性的队列称为瞬时(transient)队列，并非所有的场景都需要开启队列的持久化特性。
队列的持久化特性并不意味着路由到它上面的消息是持久化的，也就是队列的持久化跟消息的持久化是两回事。如果息中间件代理挂了，它重启后会重新声明开启了持久化特性的队列，这些队列中只有使用了消息持久化特性的消息会被恢复。
绑定绑定(Binding)是交换器路由消息到队列的规则。例如交换器E可以路由消息到队列Q，那么Q必须通过一定的规则绑定到E。绑定中使用的某些交换器的类型决定了它可以使用可选的路由键(RoutingKey)。路由键的作用类似于过滤器，可以筛选某些发布到交换器的消息路由到目标队列。
如果发布的消息没有路由到任意一个目标队列，例如，消息已经发布到交换器，交换器中没有任何绑定，这个时候消息会被丢弃或者返回给发布者，取决于消息发布者发布消息时候使用的参数。
消费者如果队列只有发布者生产消息，那么是没有意义的，必须有消费者对消息进行使用，或者叫这个操作为消息消费，消息消费的方式有两种：
消息代理中间件向消费者推送消息(推模式，代表方法是basic.consume)。
消费者主动向消息代理中间件拉取消息(拉模式，代表方法是basic.get)。
使用推模式的情况下，消费者必须指定需要订阅的队列。每个队列可以存在多个消费者，或者仅仅注册一个独占的消费者。
每个消费者(订阅者)都有一个称为消费者标签(consumer tag)的标识符，消费者标签是一个字符串。通过消费者标签可以实现取消订阅的操作。
消息确认消费者应用程序有可能在接收和处理消息的时候崩溃，也有可能因为网络原因导致消息中间件代理投递消息到消费者的时候失败了，这样就会催生一个问题：AMQP消息中间件代理应该在什么时候从队列中删除消息？因此，AMQP 0-9-1规范提供了两种选择：
消息中间件代理向应用程序发送消息(使用AMQP方法basic.deliver或basic.get-ok)。
应用程序收到消息后向消息中间件代理发送确认(使用AMQP方法basic.ack <= 个人感觉这个地方少写了basic.nack和basic.reject)
前一种称为自动确认模型(动作触发的同时进行了消息确认)，后一种称为显式确认模型。显式确认模型中，需要消费者主动向消息中间件代理进行消息主动确认，这个消息主动确认动作的执行时机完全由应用程序控制。消息主动确认有三种方式：积极确认(ack)、消极确认(nack)和拒绝(reject)。
预取消息预取消息(Prefetching Messages)是一个特性。对于多个消费者共享同一个队列的情况，能够告知消息中间件代理在发送下一个确认之前指定每个消费者一次可以接收消息的消息量。这个特性可以理解为简单的负载均衡技术，在批量发布消息的场景下能够提高吞吐量。
消息属性和有效负载AMQP模型中，消息具有属性值。AMQP 0-9-1规范定义了一些常见的属性，一般开发人员不需要太关注这些属性：
Content type
Content encoding
Routing key
Delivery mode (persistent or not)
Message priority
Message publishing timestamp
Expiration period
Publisher application id
这些通用的属性一般是消息中间件代理使用的，还有可以定制的可选属性header，形式是键值对，类似于HTTP中的请求头。消息属性是在发布消息的时候设置的。
AMQP消息还有一个有效载荷(payload，其实就是消息数据体)，AMQP代理将其视为不透明的字节数组，也就是AMQP代理不会检查或者修改消息的有效载荷。有些消息可能只包含属性而没有有效负载。通常使用序列化格式(如JSON，Thrift，Protocol Buffers和MessagePack)来序列化和结构化数据，以便将其作为消息有效负载发布。在一般约定下，消息属性中的Content type和Content encoding一般可以表明其序列化的方式。
消息发布支持消息的持久化特性，消息持久化特性开启后，消息中间件代理会把消息保存到磁盘中，如果重启代理消息也不会丢失。开启消息持久化特性将会影响性能，主要是因为涉及到刷盘操作。
AMQP-0-9-1方法