Queue AMQP 中的 隊列 的概念和其他消息隊列中 隊列 的概念類似, 它有如下幾個重要的概念: Name, 名字 Durable, 是否是持久的. 當為真時, 即使 broker 重啟時, 此 queue 也不會被刪除. Exclusive, 是否是獨占的, 當為真時, 表示此 queue 只能有一個消費者, 并且當此消費者的連接斷開時, 此 queue 會被刪除. Auto-delete, 當為真時, 此 隊列 會在最后一個消費者取消訂閱時被刪除. 在使用一個 隊列 時, 需要先進行聲明. 如果我們聲明的隊列不存在, 那么 broker 就會自動創建它. 不過如果此隊列已經存在時, 我們就需要注意了, 若我們聲明的隊列的屬性和已存在的隊列的屬性一致, 則不會有任何的問題, 但是如果先后兩次聲明的隊列的屬性不一致, 則會有 PRECONDITION_FAILED 錯誤(錯誤碼為406). 關于隊列名 AMQP 的隊列名不能以 “amq.” 開頭, 因為這樣的隊列名是 AMQP broker 內部所使用的. 當我們使用了這樣的隊列名時, 那么會有一個 ACCESS_REFUSED 錯誤(錯誤碼為 403) 關于持久隊列 持久隊列會被持久化到磁盤中, 因此即使 broker 重啟了, 持久隊列也依然存在.不過需要注意的是, 不要將持久隊列和消息的持久化混淆. 當 broker 重啟時, 持久隊列會自動重新聲明, 然而只有隊列中的持久化消息(persistent message)才會被恢復. 隊列的綁定 隊列的綁定關系是 exchagne 用于消息路由的規則, 即一個 exchange 能夠將消息路由到某個隊列的前提是此隊列已經綁定到這個 exchange 中了. 當隊列綁定到一個 exchange 中時, 我們還可以設置一個額外的參數, 即 route key, 這個 key 會被 direct exchange 和 topic exchange 作為額外的路由信息而使用, 換句話說, route key 扮演著過濾器的角色.當一個消息沒有被路由到任意的隊列時(例如此 exchange 沒有任何的 queue 綁定著), 那么此時會根據消息的屬性來決定是將此消息丟棄還是返回給生產者. 消費者 AMQP 0-9-1 支持兩種消息分發模式: push 模式, 即 broker 主動推送消息給消費者 pull 模式, 即消費者主動從 broker 中拉取消息. 在 push 模式時, 應用程序需要告知 broker 它對哪些消息感興趣, 即也就是我們所說的訂閱一個消息主題. 每個消費者都有一個惟一的標識符, 即consumer tag, 我們可以用這個 tag 來取消一個消費者對某個主題的訂閱(unsubscribe). 消息的 ACK AMQP 0-9-1 有兩種消息 ACK 模式: 自動 ACK 模式 手動 ACK 模式 在自動 ACK 模式下, 當 broker 發送消息成功后, 會立即將此消息從消息隊列中刪除, 而不會等待消費者的 ACK 回復. 而在手動 ACK 模式下, 當 broker 發送消息給消費者時, 不會立即將此消息刪除, 而是需要等待消費者的 ACK 回復后才會刪除消息. 因此在手動 ACK 模式下, 當消費者收到消息并處理完成后, 需要向 broker 顯示地發送 ACK 指令.在手動 ACK 模式下, 如果消費者因為意外的 crash 而沒有發送 ACK 給 broker, 那么此時 broker 會將此消息轉發給其他的消費者(如果此時沒有消費者了, 那么 broker 會緩存此消息, 直到有新的消費者注冊). 拒絕消息 當一個消費者處理消息失敗或此時不能處理消息時, 那么可以給 broker 發送一個拒絕消息的指令, 并且可以要求 broker 丟棄或重新分發此消息.不過需要注意的是, 如果此時只有一個消費者, 那么當此消費者拒收消息并要求 broker 重新分發此消息時, 那么就會造成了此消息不斷地分發和拒收, 形成了死循環. 預取消息 通過預取消息機制, 消費者可以一次性批量取出消息, 然后在處理后對這些批量消息進行統一的 ACK 回復, 這樣可以提高消息的吞吐量.不過, 需要注意的時, RabbitMQ 僅支持 channel 級別的預取消息的數量配置, 不支持基于連接的預取消息數量配置. 連接 AMQP 的連接是長連接, 它是一個使用 TCP 作為可靠傳輸的應用層協議.