在rabbitmq中，生產者的訊息都是通過交換器來接收，然後再從交換器分發到不同的佇列中去，在分發的過程中交換器型別會影響分發的邏輯。
rabitmq中的交換器有4種型別，分別為fanout、direct、topic、headers四種，其中前三種較為常見，後面一種用的比較少。
一般情況下交換器分發會先找出繫結的佇列，然後再判斷routekey，來決定是否將訊息分發到某乙個佇列中；但如果交換器的型別為fanout，那麼交換器就不再判斷routekey了，而是將訊息直接分發到繫結的佇列中去。如下測試**
channel channel = connection.createchannel(); //在rabbitmq中建立乙個通道
channel.exchangedeclare("exchangename", "fanout"); //建立乙個type為fanout的交換器
channel.queuedeclare("queuename"); //建立乙個佇列
channel.queuebind("queuename", "exchangename", "routingkey"); //將佇列和交換器繫結
direct的情況下，交換器在分發訊息的時候同樣會先獲取繫結的佇列，然後還會再判斷routeing;當交換器發現型別為direct，判斷routeing的規則是完全匹配模式，只有訊息完全匹配到routeing的時候，才會將訊息分發到指定佇列；
乙個佇列是可以指定多個路由鍵的，我們假設有兩個佇列,分別是佇列一、佇列二;在佇列一中指定了三個路由鍵,分別是zhangsan、lisi,wangwu,在佇列二中指定了乙個佇列鍵lisi，指定多個路由鍵的**如下所示:
channel channel = connection.createchannel(); //在rabbitmq中建立乙個通道
channel.exchangedeclare("exchangename", "direct"); //建立乙個type為direct的交換器
channel.queuedeclare("queuename"); //建立乙個佇列
channel.queuebind("queuename", "exchangename", "zhangsna"); //繫結並設定路由鍵
channel.queuebind("queuename", "exchangename", "lisi"); //繫結並設定路由鍵
channel.queuebind("queuename", "exchangename", "wangwu"); //繫結並設定路由鍵
zhangsan的訊息到交換器中，交換器在分發的時候只會把訊息分發到佇列一裡面去，因為交換器在routeting匹配的時候只匹配到了佇列一，因此佇列二不會收到訊息；
當生產者再次傳送了一條routeting為lisi的訊息到交換器中，交換器在分發的時候會把訊息分發到佇列一和佇列二兩個佇列裡面去，因為交換器在routeting匹配的時候匹配都匹配成功，因此兩個佇列都收到了訊息；
在型別為topic的情況下，交換器分發訊息的時候也需要同時匹配bindkey和routingkey；但與direct型別不同的是當交換器發現型別為topic時候，判斷routeing的規則是模糊匹配模式。
rabitmq自定義了一套匹配規則，在這裡我假設生產者傳送了乙個訊息，其中的的routingkey為wiki.imooc.com，那麼交換器為topic型別時候，想要獲取到這條訊息，可以用*號作為萬用字元，來指定routingkey,分別是*.*.com、*.imooc.*、*wiki.imooc.*;同樣也可以使用#作為萬用字元來指定路由鍵,例如wiki.#、#.com；
在上面的萬用字元列子中，我們需要掌握這幾點：
型別為headers的交換器與前面三種匹配方式完全不一樣，它不依賴與bindingkey和routingkey，而是在繫結佇列與交換器的時候指定乙個鍵值對；當交換器在分發訊息的時候會先解開訊息體裡的headers資料，然後判斷裡面是否有所設定的鍵值對，如果發現匹配成功，才將訊息分發到佇列中；這種交換器型別在效能上相對來說較差，在實際工作中很少會用到。
從訊息分發的效能上來比較：fanout>direct>topic>headerstopic的匹配規則只是用於消費者而不是生產者
訊息佇列Rabbitmq
rabbitmq server rabbitmqctl reset rabbitmqctl stop rabbitmqctl stop rabbitmqctl list users rabbitmqctl list queues rabbitmqctl add user user name user...
訊息佇列RabbitMQ
這是乙個很嚴肅的問題。系統之間解除耦合，可以讓不同語言編寫的系統通訊互動 保證伺服器負載不會飆公升。高大上一點就是流量削峰。讓程式變成非同步，提高響應速度。把費時任務放到另乙個程序或執行緒去執行。redis實現 剛開始學習redis時，一看這個鍊錶不就是給佇列準備的嗎？所以，一心扎進去，要寫個佇列出...
RabbitMQ訊息佇列
訊息發布接收流程 接收訊息 工作模式 publish subscribe 發布訂閱模式 發布訂閱publish subscribe和工作模式work queues的區別 routing 路由模式 區別 topics 區別 header 宣告佇列 bean queue inform sms publi...