作為消費者的客戶端要消費Rabbitmq的訊息，首先要建立與它某個佇列的連線，具體連線時可指定佇列的BindingKey和關係的exchange標識，Rabbitmq判斷若已有佇列通過BindingKey與exchange標識關聯則允許消費者消費佇列的訊息，否則新建一個佇列用指定的BindingKey與exchange關聯，獲取特定的訊息。若果exchange是topic型別則也可用萬用字元‘#’獲取所有發到這個exchange的訊息。

rabbitmq一個佇列類似一個消費群組，當有多個消費者都關注這個佇列訊息時，它會將訊息平均分配給各個消費者。若果不同應用消費者想要訂閱所有發到exchange的訊息，則可以建不同的group消費。

rabbitmq預設訊息、佇列、交換器（exchange）都不具有持久化的性質，如果應用需要持久化功能，那麼在宣告時要配置好。首先交換器和佇列的宣告時要指定durable引數為true，這樣重啟後佇列和交換器都會恢復。然後訊息在傳送時要在properties中指定delivery_mode = 2，這樣服務重啟後佇列中的這種訊息可以恢復。但訊息的持久化不是一個強約束，涉及資料落地的時機及系統層面同步問題，若要儘可能提高訊息的持久化有效性，可配置狀態反饋的confirm mode。

狀態反饋的目的是為了確認行為的結果。當你向exchange提交訊息時，是否提交成功，是否送達到佇列，佇列中的訊息是否被消費者正常消費等問題都要考慮。在AMQP中要確保訊息業務可靠性只能使用事務，不過rabbitmq有些簡便的擴充套件機制如狀態確認可到達同樣的目的。

rabbitmq中狀態反饋分為釋出狀態反饋和提取狀態反饋。具體釋出訊息時設定channel的confirm mode，這樣對持久化訊息被投遞到一個持久化佇列成功並且把資料寫入磁碟時會給傳送者一個狀態確認；在未關閉訊息的ack機制情況下，當訊息被consumer從佇列提取後，在未明確收到確認訊息之前，佇列中的訊息不會被刪除，而是變成等待確認狀態，當consumer反饋成功給佇列時，訊息才會被刪除，若consumer反饋拒絕給佇列，則訊息可能再被其它consumer提取。

https://www.zouyesheng.com/rabbitmq.html#toc11