廣播式交換器類型（fanout）
該類交換器不分析所接收到消息中的Routing Key，默認將消息轉發到所有與該交換器綁定的隊列中去。廣播式交換器轉發效率最高，但是安全性較低，消費者應用程序可獲取本不屬於自己的消息。
廣播交換器是最簡單的一種類型，就像我們從字面上理解到的一樣，它把所有接受到的消息廣播到所有它所知道的隊列中去，不論消息的關鍵字是什麼，消息都會被路由到和該交換器綁定的隊列中去。
它的工作方式如下圖所示：
在程序中申明一個廣播式交換器的代碼如下：
channel.exchange_declare(exchange='fanout',type='fanout')
直接式交換器類型（direct）
該類交換器需要精確匹配Routing Key與BindingKey，如消息的Routing Key = Cloud，那麼該條消息只能被轉發至Binding Key = Cloud的消息隊列中去。直接式交換器的轉發效率較高，安全性較好，但是缺乏靈活性，系統配置量較大。
相對廣播交換器來說，直接交換器可以給我們帶來更多的靈活性。直接交換器的路由算法很簡單——一個消息的routing_key完全匹配一個隊列的 binding_key，就將這個消息路由到該隊列。綁定的關鍵字將隊列和交換器綁定到一起。當消息的routing_key和多個綁定關鍵字匹配時消息
可能會被髮送到多個隊列中。
我們通過下圖來說明直接交換器的工作方式：
如圖：Q1，Q2兩個隊列綁定到了直接交換器X上，Q1的binding_key是“orange”，Q2有兩個綁定，一個binding_key是black，另一個binding_key是green。在這樣的關係下，一個帶有 “orange” routing_key的消息發送到X交換器之後將會被X路由到隊列Q1，一個帶有
“black” 或者 “green” routing_key的消息發送到X交換器之後將會被路由到Q2。而所有其他消息將會被丟失掉。
主題式交換器（Topic Exchange）
該類交換器通過消息的Routing Key與Binding Key的模式匹配，將消息轉發至所有符合綁定規則的隊列中。Binding Key支持通配符，其中“*”匹配一個詞組，“#”匹配多個詞組（包括零個）。例如，Binding Key=“*.Cloud.#”可轉發Routing
Key=“OpenStack.Cloud.GD.GZ”、“OpenStack.Cloud.Beijing”以及“OpenStack.Cloud”的消息，但是對於Routing Key=“Cloud.GZ”的消息是無法匹配的。
這裏的routing_key可以使用一種類似正則表達式的形式，但是特殊字符只能是“*”和“#”，“*”代表一個單詞，“#”代表0個或是多個單詞。這樣發送過來的消息如果符合某個queue的routing_key定義的規則，那麼就會轉發給這個queue。
緊接着說一下交換機.交換機的主要作用是接收相應的消息並且綁定到指定的隊列.交換機有四種類型,分別爲Direct,topic,headers,Fanout.
Direct是RabbitMQ默認的交換機模式,也是最簡單的模式.即創建消息隊列的時候,指定一個BindingKey.當發送者發送消息的時候,指定對應的Key.當Key和消息隊列的BindingKey一致的時候,消息將會被髮送到該消息隊列中.
topic轉發信息主要是依據通配符,隊列和交換機的綁定主要是依據一種模式(通配符+字符串),而當發送消息的時候,只有指定的Key和該模式相匹配的時候,消息纔會被髮送到該消息隊列中.
headers也是根據一個規則進行匹配,在消息隊列和交換機綁定的時候會指定一組鍵值對規則,而發送消息的時候也會指定一組鍵值對規則,當兩組鍵值對規則相匹配的時候,消息會被髮送到匹配的消息隊列中.
Fanout是路由廣播的形式,將會把消息發給綁定它的全部隊列,即便設置了key,也會被忽略.
注意：關於bingkey : 在rabbit 管理界面中，沒有這個參數，但是你操作交換機與隊列綁定時，就默認了兩者的關係。同時還有一點需要注意：關於routingkey 它是用來匹配的，但是它是用於匹配與之綁定的隊列的名字（這點很多說明介紹文檔中沒有提，導致我一直以爲routing
key 只要設置好，然後在消息進行交換機後，會對你發送消息中的routingkey 與匹配 交換機與隊列綁定時設置的key，導致數據一直接收不到）
本文參考：http://terry0501.iteye.com/blog/2329580