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