RabbitMQ 訊息佇列之 Exchange Types
訊息釋出到交換站，這通常被比作郵局或郵箱。然後交換器使用稱為繫結的規則將訊息副本分發到佇列。然後，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 則所有的值必須匹配。