Queue（队列）：
Queue参数
- durable：是否持久化, 队列默认是存放到内存中的，rabbitmq重启会丢失，如果想重启之后还存在就要使队列持久化，保存到Erlang自带的Mnesia数据库中，当rabbitmq重启之后会读取该数据库
- exclusive：是否排外的，队列在当前connection下的channel中是共享的，其他connection下的channel访问不到，当connection关闭时队列删除
- autoDelete：是否自动删除，当最后一个消费者断开连接之后队列是否自动被删除，可以通过RabbitMQ Management，查看某个队列的消费者数量，当consumers = 0时队列就会自动删除
- Arguments：队列其他参数，Dictionary类型
Arguments字典：
- x-message-ttl #消息过期时间,message在队列的最大存活时间，单位毫秒。设置后队列Features属性显示TTL。也可以对消息本身设置过期时间
- x-expires 设置队列的过期时间，如启动一个生产者或启动一个消费者，消费者运行结束后10秒，队列会被删除
- x-max-length #队列最大长度
- x-max-length-bytes #指定队列最大内存
- x-dead-letter-exchange #指定死信交换机
- x-dead-letter-routing-key #指定死信routingKey
- x-max-priority #设置优先级，优先级高的先发送consumer
- x-queue-mode #可以是default、lazy（惰性队列）。下面对lazy队列有详细说明
- x-overflow queue的溢出行为，值包括：drop-head（删除queue头部的消息）、reject-publish（最近发来的消息将被丢弃）、reject-publish-dlx（拒绝发送消息到死信交换器）
控制台队列属性：
- Features属性:
D:持久化
TTL：设置了消息过期时间
DLX、DLK：表示设置给队列设置了死信交换机和死信消息的routing key - Ready：消息的状态，等待投递的消息
- Unacked：消息的状态，已投递给消费者，但是还没收到消费者确认信号的消息。如果RabbitMQ一直没有收到消费者的确认信号，并且消费此消息的消费者已经断开连接，则RabbitMQ会安排该消息重新进入队列，等待投递给下一个消费者
惰性队列：
惰性队列会尽可能的将消息存入磁盘中，而在消费者消费到相应的消息时才会被加载到内存中，它的一个重要设计目标是能够支持更长的队列，即支持更多的消息存储。当消费者由于各种各样的原因（比如消费者下线、跌机、或者由于维护而关闭等）致使长时间不能消费消息而造成堆积时，惰性队列就很必要了。
默认情况下，当生产者将消息发送到RabbitMQ的时候，队列中的消息会尽可能地存储在内存之中，这样可以更加快速地将消息发送给消费者。即使是持久化的消息，在被写入磁盘的同时也会在内存中驻留一份备份。当RabbitMQ需要释放内存的时候，会将内存中的消息换页至磁盘中，这个操作会耗费较长的时间，也会阻塞队列的操作，进而无法接收新的消息。虽然RabbitMQ的开发者们一直在升级相关的算法，但是效果始终不太理想，尤其是在 消息量特别大的时候。
惰性队列会将接收到的消息直接存入文件系统，而不管是持久化的或者是非持久化的，这样可以减少内存的消耗，但是会增加I/O的使用，如果消息是持久化的，那么这样的I/O操作不可避免，惰性队列和持久化的消息可谓是“最佳拍档”。注意如果惰性队列中存储的是非持久化的消息，内存的使用率会一直很稳定，但是重启之后消息一样会丢失。
队列具备两种模式：default和lazy。默认的为default模式，lazy模式即为惰性队列的模式，可以通过调用channel.queueDeclare方法的时候在参数中设置，也可以通过Policy的方式设置，如果一个队列同时使用这两种方式设置，那么Policy的方式具备更高的优先级。如果要通过声明的方式改变已有队列的模式，那么只能先删除队列，然后再重新声明一个新的。
注意：
- RabbitMQ 不允许你绑定一个非坚固（non-durable）的交换机和一个durable的队列。反之亦然。要想成功必须队列和交换机都是durable的。
- 一旦创建了队列和交换机，就不能修改其标志了。例如，如果创建了一个non-durable的队列，然后想把它改变成durable的，唯一的办法就是删除这个队列然后重现创建。因此，最好仔细检查创建的标志。
- 队列、交换机可以持久化，绑定不能设置持久化，如果你绑定了一个durable的队列和一个durable的交换机，RabbitMQ会自动持久化这个绑定。
- Unacked消息怎么处理：未ack的消息状态会变为Unacked，客户端断开连接后，状态会变为Ready
- 建议使用长连接，长连接的基础之上使用多个channel