rabbitmq系列四 之主题交换机

1、主题

  在前面的例子中,我们对日志系统进行了改进。使用了direct交换机代替了fanout交换机,从只能盲目的广播消息改进为有可能选择性的接收日志。

  尽管直接交换机能够改善我们的日志系统,但是它也有它的限制——没办法基于多个标准执行路由操作。

  在我们的日志系统中,我们不只希望订阅基于日志级别,同时还希望订阅基于日志来源。其中unix工具syslog是同时基于日志的级别(info/warn/error)和设备-facility (auth/cron/kern...)来路由日志的。

  如果这样的话,将会给予我们非常大的灵活性,我们既可以监听来源于“cron”的严重程度为“critical errors”的日志,也可以监听来源于“kern”的所有日志。

  为了实现这个目的,接下来我们学习如何使用另一种更复杂的交换机 —— 主题交换机。

2、主题交换机

  发送到主题交换机(topic exchange)的消息不可以携带随意什么样子的路由键(routing_key),它的路由键必须是一个由.分隔开的词语列表。这些单词随便是什么都可以,但是最好是跟携带它们的消息有关系的词汇。以下是几个推荐的例子:"stock.usd.nyse", "nyse.vmw", "quick.orange.rabbit"。词语的个数可以随意,但是不要超过255字节。

  绑定键也必须拥有同样的格式。主题交换机背后的逻辑跟直连交换机很相似 —— 一个携带着特定路由键的消息会被主题交换机投递给绑定键与之想匹配的队列。但是它的绑定键和路由键有两个特殊应用方式:

    * (星号) 用来表示一个单词.

      # (井号) 用来表示任意数量(零个或多个)单词

  下边用图说明:

                  

  这个例子里,我们发送的所有消息都是用来描述小动物的。发送的消息所携带的路由键是由三个单词所组成的,这三个单词被两个.分割开。路由键里的第一个单词描述的是动物的手脚的利索程度,第二个单词是动物的颜色,第三个是动物的种类。所以它看起来是这样的: <celerity>.<colour>.<species>

  我们创建了三个绑定:Q1的绑定键为 *.orange.*,Q2的绑定键为 *.*.rabbit 和 lazy.# 。

这三个绑定键被可以总结为:

    Q1 对所有的桔黄色动物都感兴趣。

    Q2 则是对所有的兔子所有懒惰的动物感兴趣。

  一个携带有 quick.orange.rabbit 的消息将会被分别投递给这两个队列。携带着 lazy.orange.elephant 的消息同样也会给两个队列都投递过去。另一方面携带有 quick.orange.fox 的消息会投递给第一个队列,携带有 lazy.brown.fox 的消息会投递给第二个队列。携带有 lazy.pink.rabbit 的消息只会被投递给第二个队列一次,即使它同时匹配第二个队列的两个绑定。携带着 quick.brown.fox 的消息不会投递给任何一个队列。

  如果我们违反约定,发送了一个携带有一个单词或者四个单词("orange" or "quick.orange.male.rabbit")的消息时,发送的消息不会投递给任何一个队列,而且会丢失掉。

  但是另一方面,即使 "lazy.orange.male.rabbit" 有四个单词,他还是会匹配最后一个绑定,并且被投递到第二个队列中。

  注意:

  主题交换机是很强大的,它可以表现出跟其他交换机类似的行为

  当一个队列的绑定键为 "#"(井号) 的时候,这个队列将会无视消息的路由键,接收所有的消息。

  当 * (星号) 和 # (井号) 这两个特殊字符都未在绑定键中出现的时候,此时主题交换机就拥有的直连交换机的行为。

3、组合在一起

  接下来我们会将主题交换机应用到我们的日志系统中。在开始工作前,我们假设日志的路由键由两个单词组成,路由键看起来是这样的:<facility>.<severity>。

  代码跟上一篇教程差不多。

原文地址:https://www.cnblogs.com/Hxinguan/p/9191789.html

时间: 2024-10-10 20:53:50

rabbitmq系列四 之主题交换机的相关文章

RabbitMQ实例教程:主题交换机

前面的例子中,尽管我们使用了direct路由代替fanout路由解决了盲目广播的问题,但direct路由也有它的缺陷,他不能基于多个标准做路由转发. 在上面的日志系统中,如果不仅想基于日志等级做订阅,也想根据日志的发生源做订阅该怎么处理呢?这时候你可能想到了unix系统工具中的syslog服务,它不仅基于日志等级(info/warn/crit...)进行路由转发,也会根据操作(auth/cron/kern...)做路由转发. 如果是那样的话,日志系统就灵活多了,它不仅能够监听来自'cron'的关

RabbitMQ学习 (五):主题交换机

尽管直连交换机能够改善我们的系统,但是它也有它的限制 -- 没办法基于多个标准执行路由操作. 为了实现这个目的,接下来我们学习如何使用另一种更复杂的交换机 -- 主题交换机. 发送到主题交换机(topic exchange)的消息不可以携带随意什么样子的路由键(routing_key),它的路由键必须是一个由.分隔开的词语列表.这些单词随便是什么都可以,但是最好是跟携带它们的消息有关系的词汇.以下是几个推荐的例子:"stock.usd.nyse", "nyse.vmw&quo

rabbitmq系列四 之路由

1.路由 在上一个的教程中,我们构建了一个简单的日志记录系统.我们能够向许多接收者广播日志消息. 在本次教程中,我们向该系统添加一些特性,比如,我只需要严重错误(erroe级别)的部分日志打印到磁盘文件中,但是同时仍然把所有的日志打印到控制台. 2.绑定 在前面的例子中.我们已经用以下的代码创建了绑定. 1 channel.queueBind(queueName, EXCHANGE_NAME, ""); 绑定是指交换机(exchange)与队列(queue)之间的联系,也可以理解为,当

RabbitMQ入门教程(七):主题交换机Topics

原文:RabbitMQ入门教程(七):主题交换机Topics 版权声明:本文为博主原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明. 本文链接:https://blog.csdn.net/vbirdbest/article/details/78631035 分享一个朋友的人工智能教程.比较通俗易懂,风趣幽默,感兴趣的朋友可以去看看. 简介 本节主要演示交换机的另一种类型:主题类型topic,直连接类型direct必须是生产者发布消息指定的routingKey和消费者

rabbitMq及安装、fanout交换机-分发(发布/订阅)

<dependency>            <groupId>com.rabbitmq</groupId>            <artifactId>amqp-client</artifactId>            <version>3.6.5</version> </dependency> 最常见的几种消息通信模式主要有发布-订阅.点对点这两种http://blog.csdn.net/wooge

C++的性能C#的产能?! - .Net Native 系列四:性能测试方法(PerfView)

之前一文<c++的性能, c#的产能?!鱼和熊掌可以兼得,.NET NATIVE初窥> 获得很多朋友支持和鼓励,也更让我坚定做这项技术的推广者,希望能让更多的朋友了解这项技术,于是先从官方信息的翻译开始做起. 此系列系小九的学堂原创翻译,翻译自微软官方开发向导,一共分为六个主题.本文是第四个主题:.NET Native性能测试. 向导文链接:<C++的性能C#的产能?! - .Net Native 系列:开发向导> [小九的学堂,致力于以平凡的语言描述不平凡的技术.如要转载,请注明

RabbitMQ(五) ——主题

RabbitMQ(五) --主题 (转载请附上本文链接--linhxx) 一.概述 话题模式(topic)可以让队列绑定某一类型的消息,而不仅仅是direct模式下的具体的消息.即,其允许绑定的信息采用通配符.可以保证多重条件下,仍具备灵活性.但是,当routing key没有匹配时,仍然会丢弃消息. 话题模式如下图所示: 二.话题模式的交换机(topic exchange) 该模式下,routing key更加灵活,支持通配符.但是,并没有正则表达式那么强大的匹配,其主要支持两个通配符.匹配是

RabbitMQ(四) ——路由

RabbitMQ(四) --路由 (转载请附上本文链接--linhxx) 一.概述 路由模式(routing)是交换机不将消息广播到全部的队列中,而是采用交换机的另一种模式--direct.该模式下,交换机会精准的将消息发送到某个与其绑定的队列,而不是发送给全部队列. 如果没有队列绑定交换机,消息会丢失. 路由模式如下图所示: 二.绑定方式(binding) 在交换机的fanout模式下,不需要routing key,但是在此模式下,由于交换机需要精准的将消息发送给某个(某些)队列,则需要队列与

rabbitmq系列三 之发布/订阅

1.发布/订阅 在上篇教程中,我们搭建了一个工作队列,每个任务只分发给一个工作者(worker).在本篇教程中,我们要做的跟之前完全不一样 -- 分发一个消息给多个消费者(consumers).这种模式被称为"发布/订阅". 为了描述这种模式,我们将会构建一个简单的日志系统.它包括两个程序--第一个程序负责发送日志消息,第二个程序负责获取消息并输出内容. 在我们的这个日志系统中,所有正在运行的接收方程序都会接受消息.我们用其中一个接收者(receiver)把日志写入硬盘中,另外一个接受