訊息佇列Rabbitmq的交換器型別
一、交換器型別
在rabbitmq中,生產者的訊息都是透過交換器來接收,然後再從交換器分發到不同的佇列中去,在分發的過程中交換器型別會影響分發的邏輯。
rabitmq中的交換器有4種型別,分別為fanout、direct、topic、headers四種,其中前三種較為常見,後面一種用的比較少。
二、fanout
一般情況下交換器分發會先找出繫結的佇列,然後再判斷routekey,來決定是否將訊息分發到某一個佇列中;但如果交換器的型別為fanout,那麼交換器就不再判斷routekey了,而是將訊息直接分發到繫結的佇列中去,如下測試程式碼
Channel channel = connection.createChannel(); //在rabbitmq中建立一個通道
channel.exchangeDeclare("exchangeName", "fanout"); //建立一個type為fanout的交換器
channel.queueDeclare("queueName"); //建立一個佇列
channel.queueBind("queueName", "exchangeName", "routingKey"); //將佇列和交換器繫結
三、direct
在型別為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"); //繫結並設定路由鍵
當生產者傳送了一條routeting為zhangsan的訊息到交換器中,交換器在分發的時候只會把訊息分發到佇列一里面去,因為交換器在routeting匹配的時候只匹配到了佇列一,因此佇列二不會收到訊息;
當生產者再次傳送了一條routeting為lisi的訊息到交換器中,交換器在分發的時候會把訊息分發到佇列一和佇列二兩個佇列裡面去,因為交換器在routeting匹配的時候匹配都匹配成功,因此兩個佇列都收到了訊息;
四、topic
在型別為topic的情況下,交換器分發訊息的時候也需要同時匹配bindKey和routingKey;但與direct型別不同的是當交換器發現型別為topic時候,判斷routeing的規則是模糊匹配模式。
rabitmq自定義了一套匹配規則,在這裡我假設生產者傳送了一個訊息,其中的的routingKey為wiki.imooc.com,那麼交換器為topic型別時候,想要獲取到這條訊息,可以用*號作為萬用字元,來指定routingKey,分別是*.*.com、*.imooc.*、*wiki.imooc.*;同樣也可以使用#作為萬用字元來指定路由鍵,例如wiki.#、#.com;
在上面的萬用字元列子中,我們需要掌握這幾點:
- 路由鍵以.為分隔符,每一個分隔符的代表一個單詞
- 萬用字元*匹配一個單詞、萬用字元#可以匹配多個單詞
- *可以在routingKey和bindKey上使用,#只能用於RoutingKey中
五、headers
型別為headers的交換器與前面三種匹配fang式完全不一樣,它不依賴與bindingKey和routingKey,而是在繫結佇列與交換器的時候指定一個鍵值對;當交換器在分發訊息的時候會先解開訊息體裡的headers資料,然後判斷裡面是否有所設定的鍵值對,如果發現匹配成功,才將訊息分發到佇列中;這種交換器型別在效能上相對來說較差,在實際工作中很少會用到。
六、小結
- 從訊息分發的效能上來比較:fanout > direct > topic > headers
- topic的匹配規則只是用於消費者而不是生產者
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69923331/viewspace-2691628/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- RabbitMQ訊息佇列MQ佇列
- [訊息佇列]RabbitMQ佇列MQ
- RabbitMQ 訊息佇列之佇列模型MQ佇列模型
- MQ訊息佇列_RabbitMQMQ佇列
- rabbitmq訊息佇列原理MQ佇列
- 訊息佇列之RabbitMQ佇列MQ
- 訊息佇列之 RabbitMQ佇列MQ
- RabbitMQ 訊息佇列 配置MQ佇列
- RabbitMQ訊息佇列(五):Routing 訊息路由MQ佇列路由
- RabbitMQ 訊息佇列之 Exchange TypesMQ佇列
- RabbitMQ訊息佇列(二):”Hello, World“MQ佇列
- RabbitMQ訊息佇列系列教程(一)認識RabbitMQMQ佇列
- 訊息佇列的使用場景之RabbitMQ佇列MQ
- 總結訊息佇列RabbitMQ的基本用法佇列MQ
- RabbitMQ訊息佇列(九):Publisher的訊息確認機制MQ佇列
- 再看rabbitmq的交換器和佇列的關係MQ佇列
- SpringBoot:初探 RabbitMQ 訊息佇列Spring BootMQ佇列
- Laravel5.6 整合 RabbitMQ 訊息佇列LaravelMQ佇列
- RabbitMQ .NET訊息佇列使用入門(五)【RabbitMQ例子】MQ佇列
- RabbitMQ,RocketMQ,Kafka 幾種訊息佇列的對比MQKafka佇列
- RabbitMQ訊息佇列(六):使用主題進行訊息分發MQ佇列
- RabbitMQ .NET訊息佇列使用入門(四)【RabbitMQ用法大全】MQ佇列
- RabbitMQ訊息佇列-Centos7下安裝RabbitMQ3.6.1MQ佇列CentOS
- 訊息佇列系列一:訊息佇列應用佇列
- RabbitMQ訊息佇列的小夥伴: ProtoBuf(Google Protocol Buffer) [轉]MQ佇列GoProtocol
- Java訊息佇列:RabbitMQ與Kafka的整合與應用Java佇列MQKafka
- 訊息佇列佇列
- RabbitMQ學習(三)之 “訊息佇列高階使用”MQ佇列
- RabbitMQ高階之訊息限流與延時佇列MQ佇列
- RabbitMQ訊息佇列(三):任務分發機制MQ佇列
- 【RabbitMQ】三種型別交換器 Fanout,Direct,TopicMQ型別
- 誰才是最快的訊息佇列:ActiveMQ, RabbitMQ, HornetQ, QPID佇列MQ
- 架構設計之NodeJS操作訊息佇列RabbitMQ架構NodeJS佇列MQ
- 基於訊息佇列(RabbitMQ)實現延遲任務佇列MQ
- RabbitMQ訊息佇列(一): Detailed Introduction 詳細介紹MQ佇列AI
- 訊息佇列(MQ)佇列MQ
- Kafka訊息佇列Kafka佇列
- kafka 訊息佇列Kafka佇列