This is the fourth installment to the series: RabbitMQ for Windows. In the last installment, we reviewed our Hello World example and introduced the concept of Exchanges. In this installment, we’ll discuss the four basic types of RabbitMQ exchanges.

Exchange Types

Exchanges control the routing of messages to queues. Each exchange type defines a specific routing algorithm which the server uses to determine which bound queues a published message should be routed to.

RabbitMQ provides four types of exchanges: Direct, Fanout, Topic, and Headers.

Direct Exchanges

The Direct exchange type routes messages with a routing key equal to the routing key declared by the binding queue.[PunCha:作者想表達的是：這個RoutingKey是在綁定Exchange和Queue的時候指定的。]. The following illustrates how the direct exchange type works:

The Direct exchange type is useful when you would like todistinguish messages published to the same exchange using a simple string identifier. This is the type of exchange that was used in our Hello World example. As discussed in part 3 of our series, every queue is automatically bound to a default exchange using a routing key equal to the queue name. This default exchange is declared as a Direct exchange. In our example, the queue named “hello-world-queue” was bound to the default exchange with a routing key of “hello-world-queue”, so publishing a message to the default exchange (identified with an empty string) routed the message to the queue named “hello-world-queue”.

Fanout Exchanges

The Fanout exchange type routes messages to all bound queues indiscriminately. If a routing key is provided, it will simply be ignored. The following illustrates how the fanout exchange type works:

The Fanout exchange type is useful for facilitating the publish-subscribe pattern. When using the fanout exchange type, different queues can be declared to handle messages in different ways. For instance, a message indicating a customer order has been placed might be received by one queue whose consumers fulfill the order, another whose consumers update a read-only history of orders, and yet another whose consumers record the order for reporting purposes.

Topic Exchanges

The Topic exchange type routes messages to queues whose routing key matches all, or a portion of a routing key. With topic exchanges, messages are published with routing keys containing a series of words separated by a dot (e.g. “word1.word2.word3”). Queues binding to a topic exchange supply a matching pattern for the server to use when routing the message. Patterns may contain an asterisk (“*”) to match a word in a specific position of the routing key, or a hash (“#”) to match zero or more words. For example, a message published with a routing key of “honda.civic.navy” would match queues bound with “honda.civic.navy”, “*.civic.*”, “honda.#”, or “#”, but would not match “honda.accord.navy”, “honda.accord.silver”, “*.accord.*”, or “ford.#”. The following illustrates how the fanout exchange type works:

The Topic exchange type is useful for directing messages based on multiple categories (e.g. product type and shipping preference ), or for routing messages originating from multiple sources (e.g. logs containing an application name and severity level).

Headers Exchanges

The Headers exchange type routes messages based upon amatching of message headers to the expected headers specified by the binding queue. The headers exchange type is similar to the topic exchange type in that more than one criteria can be specified as a filter, but the headers exchange differs in that its criteria is expressed in the message headers as opposed to the routing key, may occur in any order, and may be specified as matching any or all of the specified headers. The following illustrates how the headers exchange type works: [PunCha：註意裏面有一個x-match, any和all的區別]

The Headers exchange type is useful for directing messages which may contain a subset of known criteria where the order is not established and provides a more convenient way ofmatching based upon the use of complex types as the matching criteria (i.e. a serialized object).

Conclusion

That wraps up our introduction to each of the exchange types. Next time, we’ll walk through an example which demonstrates declaring a direct exchange explicitly and take a look at the the push API.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

最新版本的RabbitMQ有四種交換機類型，分別是Direct exchange、Fanout exchange、Topic exchange、Headers exchange。

Direct Exchange – 處理路由鍵。需要將一個隊列綁定到交換機上，要求該消息與一個特定的路由鍵完全匹配。這是一個完整的匹配。如果一個隊列綁定到該交換機上要求路由鍵 “dog”，則只有被標記為“dog”的消息才被轉發，不會轉發dog.puppy，也不會轉發dog.guard，只會轉發dog。

Fanout Exchange – 不處理路由鍵。你只需要簡單的將隊列綁定到交換機上。一個發送到交換機的消息都會被轉發到與該交換機綁定的所有隊列上。很像子網廣播，每臺子網內的主機都獲得了一份復制的消息。Fanout交換機轉發消息是最快的。

Topic Exchange – 將路由鍵和某模式進行匹配。此時隊列需要綁定要一個模式上。符號“#”匹配一個或多個詞，符號“*”匹配不多不少一個詞。因此“audit.#”能夠匹配到“audit.irs.corporate”，但是“audit.*” 只會匹配到“audit.irs”。我在RedHat的朋友做了一張不錯的圖，來表明topic交換機是如何工作的：

註：這種情況下隊列會收到所有路由器中符合topic規則的消息

Headers exchange – 還沒有仔細研究過，復制點官方的介紹吧。

A headers exchange is designed to for routing on multiple attributes that are more easily expressed as message headers than a routing key. Headers exchanges ignore the routing key attribute. Instead, the attributes used for routing are taken from the headers attribute. A message is considered matching if the value of the header equals the value specified upon binding.

It is possible to bind a queue to a headers exchange using more than one header for matching. In this case, the broker needs one more piece of information from the application developer, namely, should it consider messages with any of the headers matching, or all of them? This is what the "x-match" binding argument is for. When the "x-match" argument is set to "any", just one matching header value is sufficient. Alternatively, setting "x-match" to "all" mandates that all the values must match.

Headers exchanges can be looked upon as "direct exchanges on steroids". Because they route based on header values, they can be used as direct exchanges where the routing key does not have to be a string; it could be an integer or a hash (dictionary) for example.

其實除了上面四種以外還有一種Default Exchange，它是一種特別的Direct Exchange。

當你手動創建一個隊列時，後臺會自動將這個隊列綁定到一個名稱為空的Direct類型交換機上，綁定路由名稱與隊列名稱相同。有了這個默認的交換機和綁定，我們就可以像其他輕量級的隊列，如Redis那樣，直接操作隊列來處理消息。不過只是看起來是，實際上在RabbitMQ裏直接操作是不可能的。消息始終都是先發送到交換機，由交換級經過路由傳送給隊列，消費者再從隊列中獲取消息的。不過由於這個默認交換機和路由的關系，使我們只關心隊列這一層即可，這個比較適合做一些簡單的應用，畢竟沒有發揮RabbitMQ的最大功能，如果都用這種方式去使用的話就真是殺雞用宰牛刀了。

rabbitmq exchange type