RabbitMQ 消息路由模式/交換器
《RabbitMQ系列》： 1 .? RabbitMQ 與 AMQP 協(xié)議
2 .? RabbitMQ 消息屬性詳解 3.? RabbitMQ 可靠性與性能的平衡
4.? RabbitMQ 消費(fèi)消息
消息路由模式
RabbitMQ 最強(qiáng)大之處就在于其靈活性：它能根據(jù)消息發(fā)布方提供的路由信息，將消息路由到不同的隊列中。不論是將消息發(fā)往單個隊列、多個隊列、交換器，還是另一個由交換器插件提供的外部源，RabbitMQ 的路由引擎能始終保持極快的速度和靈活性。
通過 direct 交換器路由消息
當(dāng)需要投遞的消息有一個確定的目標(biāo)（或者多個目標(biāo)）時，direct 交換器就能派上用場。任何綁定在交換器上的隊列，只要它的路由鍵和發(fā)布消息時的一致，它就能收到消息。
對于 direct 交換器來說，RabbitMQ 在檢查綁定時會比較字符串是否相等。此時不允許使用任何類型的模式匹配。
如下圖，使用了 direct 交換器，消息發(fā)布者1發(fā)布的消息將會路由至隊列1和隊列2，而消息發(fā)布者2發(fā)布的消息將會路由至隊列2和隊列3中：
directRabbitMQ 內(nèi)置了 direct 交換器，所以不需要額外的插件。要創(chuàng)建一個 direct 交換器非常簡單，只需要將其聲明為 direct 即可。
它非常適用于 RPC 消息通信模式下的路由應(yīng)答消息。對于那些需要使用由多臺服務(wù)器提供的不同組件的應(yīng)用來說，使用 RPC 來解除應(yīng)用耦合正是實(shí)現(xiàn)高度可擴(kuò)展性的良方。
通過 fanout 交換器廣播消息
所有發(fā)往 fanout 交換器的消息會被投遞到所有綁定到該交換器上的隊列中。由于 RabbitMQ 不需要在投遞消息時檢測路由鍵，這將帶來可觀的性能優(yōu)勢。
fanout 交換器提供了非常棒的方式，讓每一個消費(fèi)者都能訪問到原始數(shù)據(jù)。不過這也是一把雙刃劍，因?yàn)橄M(fèi)者無法對收到的消息進(jìn)行選擇。
使用 topic 交換器有選擇地路由消息
topic 交換器會將消息路由至匹配路由鍵的任一隊列中。通過采用句點(diǎn)分隔的形式，隊列可以通過使用基于通配符的模式匹配的方式來綁定到路由鍵上。通過使用星號（*）和井號（#）字符，可以在同一時刻匹配路由鍵的特定部分，甚至是多個部分。星號將會匹配路由鍵中下一個句點(diǎn)前的所有字符，而井號鍵將會匹配接下來所有的字符，包括句點(diǎn)。
下圖展示了由三部分組成的 topic 交換器路由鍵：
topic 交換器topic 交換器是消息路由的極佳選擇，它使得單一用途的消費(fèi)者能夠?qū)ο⑦M(jìn)行不同的處理。如下圖，基于路由鍵的構(gòu)造方式，消息會被有選擇地路由到不同的隊列中去：
topic 交換器路由利用這種體系結(jié)構(gòu)的單一用途的消費(fèi)者可以更容易維護(hù)和擴(kuò)展。
注意：創(chuàng)建富含消息語義的路由鍵很有用。它能夠描述消息的意圖或內(nèi)容。相對于基于應(yīng)用程序的細(xì)節(jié)來設(shè)計消息及其路由鍵來說，基于事件的通用消息通信則鼓勵消息的可重用性。當(dāng)開發(fā)人員能夠在應(yīng)用程序中復(fù)用現(xiàn)有消息時，代碼復(fù)雜性降低以及消息吞吐量降低是最顯而易見的優(yōu)勢。
當(dāng)進(jìn)行路由鍵的的完全匹配時，topic 和 direct 交換器之間幾乎沒有差異。但是，通過使用 topic 交換器，將能對路由鍵進(jìn)行部分模式匹配，將來若有其他用途時也不必改動現(xiàn)有的消息通信架構(gòu)。
使用 headers 交換器有選擇地路由消息
headers 交換器通過采用消息屬性中的 headers 表支持任意的路由策略。綁定至 headers 交換器的隊列會向 Queue.Bind 參數(shù)中傳入鍵值對數(shù)組以及 x-match 參數(shù)。x-match 參數(shù)是字符串類型，可以設(shè)置為 any 或者 all 。如果將其設(shè)置為 any ，同時 headers 表中的值匹配了任何一個綁定值的話，消息就會被路由過去。如果將 x-match 設(shè)置為 all 的話 ，那么所有傳入 Queue.Bind 中的參數(shù)值必須全部匹配才行。這并不排除消息在 headers 表中擁有額外的鍵值對。
盡管 headers 交換器通過 any 和 all 匹配能力確實(shí)增添了額外的靈活性，但同時也帶來了額外的路由計算開銷。在使用 headers 交換器路由消息時，headers 屬性中的所有值必須在計算值之前按照鍵的名稱進(jìn)行排序。傳統(tǒng)觀點(diǎn)認(rèn)為，由于額外的計算復(fù)雜性，headers 交換器比其他交換器類型要慢得多。
交換器間綁定
RabbitMQ 團(tuán)隊往 RabbitMQ 中添加了一種非常靈活的機(jī)制（未包含在 AMQP 規(guī)范中），允許將消息路由至交換器的任意組合。從而使得應(yīng)用程序可以使用交換器的一部分功能加上另一種交換器的另一部分功能。
交換器間的綁定類似于隊列綁定，與將隊列綁定至交換器上不同的是，需要使用 RPC 方法 Exchange.Bind 將一個交換器綁定至另一個交換器上。
當(dāng)使用交換器間綁定時，綁定交換器的路由邏輯和綁定隊列是一致的。任何交換器都可以綁定到任何一個內(nèi)建類型的交換器上。
作為一種工具，交換器間綁定為消息通信模式帶來了巨大的靈活性。但是這一靈活性也伴隨著額外的復(fù)雜性和開銷。
使用一致性哈希交換器路由消息
一致性哈希交換器（consistent-hashing exchange）插件隨著 RabbitMQ 一同發(fā)布，將數(shù)據(jù)分發(fā)給綁定的隊列上。可為用于接收消息的隊列做負(fù)載均衡。
相比 RabbitMQ 將消息分發(fā)至單個隊列的多個消費(fèi)者來說，它提供了潛在的更為快速的吞吐量。當(dāng)使用數(shù)據(jù)庫或其他系統(tǒng)以消費(fèi)者的身份直接集成至 RabbitMQ 上時，一致性哈希交換器提供了擴(kuò)展數(shù)據(jù)的能力而無須編寫中間件。
注意
如果考慮使用一致性哈希交換器來提升消費(fèi)者吞吐量的話，應(yīng)當(dāng)為以下兩種場景建立基準(zhǔn)測試并加以區(qū)分：單隊列多消費(fèi)者和僅有單個消費(fèi)者的多個隊列。這樣一來就能辨別出哪一種選擇更合適。
一致性哈希交換器采用一致性哈希算法來決定哪個隊列將會收到消息。不同于將隊列綁定至路由鍵或者頭信息，隊列將被綁定至一個基于整型的權(quán)重值。算法的一部分采用該權(quán)重值來決定消息應(yīng)如何投遞。假設(shè)有兩個隊列綁定在了一致性哈希交換器上，并且這兩個隊列由相同的權(quán)重，那么消息的分發(fā)會接近于五五開。
一致性哈希交換器不會輪詢（round-robin）消息，而是基于路由鍵或消息屬性中 header-type 值的哈希值來作出明確的路由。不過，相較而言，擁有更高權(quán)重的隊列將能從交換器接收到更高比例的消息。
值得注意的是，由于一致性哈希算法的工作方式，如果變更了綁定至交換器的隊列總數(shù)的話，那么消息的分布極有可能會跟著發(fā)生變化。
