消息發佈到交換站，這通常被比作郵局或郵箱。然後交換器使用稱為綁定的規則將消息副本分發到隊列。然後，AMQP代理將消息傳遞給訂閱隊列的消費者，或者根據需要從隊列中獲取消息。
發佈消息時，發佈者可以指定各種消息屬性(消息元數據)。這些元數據中的一些可能由代理使用，但是，其他部分對代理完全不透明，僅供接收消息的應用程序使用。
網絡是不可靠的，應用程序可能無法處理消息，因此 AMQP 模型有消息確認的概念:當消息被交付給使用者時，使用者會自動通知代理，或者只要應用程序開發人員選擇這樣做就會通知代理。在使用消息確認時，代理只會在收到該消息(或消息組)的通知時從隊列中完全刪除消息。
例如，在某些情況下，當消息不能被路由時，消息可能被返回給發佈者或者刪除，如果代理實現了擴展，則將消息放入所謂的 dead letter queue 中。發佈者通過使用某些參數發佈消息來選擇如何處理這種情況。
隊列、交換和綁定統稱為AMQP實體。
簡介
交換機是發送消息的AMQP實體。交換機獲取消息並將其路由到零或多個隊列。所使用的路由算法取決於交換類型（Exchange Types）和被稱為綁定（Bindings）的規則。AMQP 0—9-1協議提供四種交換類型：
- Direct exchange
- Fanout exchange
- Topic exchange
- Headers exchange
Default Exchange
Default Exchange 是由代理預先聲明的無名稱（空字符串）的直接交換。它有一個特殊的屬性，使得它對於簡單的應用程序非常有用：每一個創建的隊列都自動綁定到路由鍵(Routing Key)為隊列名稱(Queue Name)的交換機。
Direct Exchange
Direct Exchange 基於消息路由鍵將消息傳遞到隊列。直接交換對於消息的單播路由來說是理想的（儘管它們也可以用於多播路由）。它的運作方式如下：
隊列綁定到具有路由鍵(Routing Key) K 的交換機。
當具有路由鍵(Routing Key) R 的新消息到達直接交換時，如果 K = R，則將其路由到隊列。
直接交換通常用於以循環方式在多個 workers（同一應用程序的實例）之間分配任務。當這樣做時，消息在消費者之間而不是在隊列之間是負載平衡的。
Fanout Exchange
Fanout Exchange 將消息路由到綁定到它的所有隊列，並且忽略路由鍵(Routing Key) 。如果N個隊列綁定到 Fanout Exchange ，則當向該交換機發布新消息時，將向所有N個隊列傳遞消息的副本。 Fanout Exchange 是廣播消息路由的理想選擇。
Fanout Exchange 向每個綁定到它的隊列傳遞消息副本，適用場景如下：
- 大型多人在線（MMO）遊戲可用於排行榜更新或其他全球性事件。
- 體育新聞網站可以使用 Fanout Exchange 來實時更新移動客戶端的評分更新。
- 分佈式系統可以廣播各種狀態和配置更新
Topic Exchange
Topic Exchange 基於消息路由鍵(Routing Key)和用於將隊列綁定到交換機的模式之間的匹配，將消息路由到一個或多個隊列。 Topic Exchange 通常用於實現各種發佈/訂閱模式變化。 Topic Exchange 通常用於消息的多播路由。
每當問題涉及多個消費者/應用程序，它們有選擇地選擇它們想要接收哪種類型的消息時，應該考慮使用 Topic Exchange 。
示例用途：
- 分配與特定地理位置相關的數據，例如銷售點
- 後臺任務處理由多個工人完成，每個任務都能夠處理特定的任務集。
- 股票價格的更新（以及其他類型的金融數據的更新）
- 涉及分類或標記的新聞更新（例如，僅針對特定的運動或團隊）
- 雲中不同類型服務的編排
- 分佈式體系結構/ OS特定的軟件構建或打包，其中每個構建器只能處理一個體繫結構或操作系統。
Headers Exchange
Headers Exchange 被設計用於在多個屬性上進行路由，這些屬性比路由鍵(Routing Key)優先級更高。 Headers Exchange 忽略路由鍵屬性。相反，用於路由的屬性是從頭屬性獲取的。如果報頭的值等於綁定時指定的值，則認為消息是匹配的。
可以使用多個報頭將隊列綁定到頭交換，以便進行匹配。在這種情況下，代理需要應用程序開發人員提供一條信息，即，它是否應該考慮與任何頭部匹配的消息，或者所有頭部匹配的消息？這就是 x-match 綁定的論點。當 x-match 參數設置為 any 時，只有一個匹配的頭值就足夠了。或者，將 x-match 設置為 all 則所有的值必須匹配。
