RabbitMQ实践——交换器(Exchange)和绑定(Banding)


RabbitMQ在概念上由三部分组成:

  • 交换器(Exchange):负责接收消息发布者发布消息的结构,同时它会根据“绑定关系”(Banding)将消息投递到符合规则的队列中。
  • 队列(Queue):消息索引组成的先进先出(FIFO)结构。交换器会将消息投递到该结构,消费者会消费该结构上的数据。它相当于一个仓储。
  • 绑定关系(Banding):用于定义交换器投递消息到队列的规则。
    在这里插入图片描述
    本文我们将关注交换器(Exchange)和绑定(Banding)部分,观察它们是如何协作将消息投递到对应队列中。
    本文仍然使用《RabbitMQ实践——在管理后台测试消息收发功能》中介绍的方法,直接在后台上操作,不涉及任何代码。RabbitMQ已经给我们初始化了各种交换器,我们将基于它们去做测试。
    实验之前,我们先建立若干个队列。具体方法如下
    在这里插入图片描述

direct型交换器

direct是最普通和常用的交换器。它可以将一个消息投递到一个或者多个队列,但是它只能使用Banding中的Routing key做完全匹配。也就说,只有消息中的Routing key和Banding中的Routing key完全一致时,才会将消息投递到Banding对应的队列中
在这里插入图片描述

默认交换器

默认交换器是一种direct型交换器。它简化了绑定关系(Banding),即用户不需要自己定义绑定关系(Banding),而是将队列的名称作为Routing Key使用。这样只要消息的Routing Key是队列名称,发送到该交换器后,就会被投递到对应的队列上。默认的,所有队列都会和默认交换器关联
在这里插入图片描述

默认交换器位于如下位置
在这里插入图片描述
然后使用下面方法发送Routing key为named_queue_a、named_queue_c和named_queue_d的消息
在这里插入图片描述
由于named_queue_a、named_queue_c这两个队列存在,所以在发送Routing key为named_queue_a、named_queue_c的消息时,会看到如下提示。
在这里插入图片描述
但是named_queue_d队列不存在,所以发送Routing key为named_queue_d的消息会失败。
在这里插入图片描述
在队列页面,我们看到named_queue_a、named_queue_c各有一条消息,而named_queue_b则没有,因为我们没有发送Routing key为named_queue_b的消息到默认交换器。
在这里插入图片描述

命名交换器

命令交换器并不会自动和所有队列关联,它需要通过绑定关系(Banding)来定义投递规则来将交换器和队列关联起来。
我们使用下面的交换器做测试在这里插入图片描述
然后使用下面的步骤新增三个绑定关系(Banding)
在这里插入图片描述
最终关系如下
在这里插入图片描述
最后发送消息,消息的Routing key是to_b。
可以在队列表中看到消息被投递到named_queue_b队列上。
在这里插入图片描述
在这里插入图片描述

fanout型交换器

fanout型交换器是一种扇出型交换器。它将消息投递到所有和它绑定的队列上。
这次我们使用的是下图的交换器
在这里插入图片描述
然后配置Banding关系。这次我们只要指定队列名称,而不用指定Routing key。(即使指定了Routing Key,也不会生效)
在这里插入图片描述
绑定完三个队列后
在这里插入图片描述
然后发布一条消息,只用指定内容,不用指定Routing key。
在这里插入图片描述
可以看到这条消息被发布到三个队列里了。
在这里插入图片描述
在这里插入图片描述

topic型交换器

之前介绍的direct型交换器要求Routing key完全相同才能投递,这明显限制了灵活性。而Topic型交换器则支持Routing key的简单正则匹配。之所以成为“简单”,是因为它只支持*和#通配符。
Topic型交换器的Routing key要组织形式是:通过.分割的字符串,比如a.b.c。
*表示通配所有.号之前的内容;#表示通配所有字符(包括后续的.)。
举一些例子:

  • a..:可以匹配a.b.c,但是不能匹配a.b.c.d。这是因为a.*.*结构要求只有3段,而a.b.c.d有4段。
  • a.#:可以匹配a.b.c和a.b.c.d,但是不能匹配b.c.d.a。
  • #.c:可以匹配a.c、a.b.c,但是不能匹配a.b.c.d、c.d.e。

这次我们使用下面的转换器
在这里插入图片描述

如下配置出下面的Banding关系,即只要Routing key中某段(两.之间,或者开头和结尾)是a,则投递到队列named_queue_a。以此类推named_queue_b和named_queue_c。
如果我们发送的Routing key是a.b.c的消息
在这里插入图片描述
则会按照Banding规则,投递到对应的队列上。
在这里插入图片描述
这儿需要注意一点:如果通配规则有重叠,即消息的Routing key匹配了多个通配规则,而这些通配规则都是投递到1个队列上,则消息只会被投递到该队列上1次,而不是匹配的次数。
比如Routing key是a.a.a的消息,它匹配了a.#、#.a.#和#.a这些规则。这些规则都指向了named_queue_a。这时这条消息只会被投递到队列named_queue_a上一次。
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

headers型交换器

Header型交换器不像direct和topic型需要匹配Routing key,而是匹配Banding中的Argument和Message中的Header。它有两种模式:

  • 完全相同:Message中的Header保存的键值对都在Banding中的Argument的键值对中,则匹配上。需要Banding的Argument设置x-match=all
  • 部分匹配:Message中的Header保存的键值对部分在Banding中的Argument的键值对中,则匹配上。需要Banding的Argument设置x-match=any

这次我们使用下图的交换器
在这里插入图片描述
然后配置如下的Banding关系
在这里插入图片描述
如果消息Header中有from=a和to=b的,会被投递到named_queue_b。
在这里插入图片描述

如果消息Header中有from=a或者to=c的,会被投递到named_queue_c。
在这里插入图片描述
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

breaksoftware

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值