RabbitMQ(二)——七种消息收发机制(直连、扇形、主题、Hearder交换机)、RPC调用、消息有效期和死信队列(单条消息过期、特殊情况、死信队列、死信队列典型应用)、延迟队列第一种实现方式

RabbitMQ(二)——七种消息收发机制(直连、扇形、主题、Hearder交换机)、RPC调用、消息有效期和死信队列(单条消息过期、特殊情况、死信队列、死信队列典型应用)、延迟队列第一种实现方式

一、七种消息收发机制

以上的例子,消息都是推过来我们接收的。用推的方式消费的节奏不能自己控制,是 rabbitMQ 控制的。如果是拉的话,可以自己控制消费的节奏。

1、并发消费+直连交换机

a、并发消费

在这里插入图片描述
上图中,如果并发数是 10 个,相当于 10 个消费者了;如果去图形化界面查看,可以发现此时有 11 个消费者。

生产者:
在这里插入图片描述
现在 11 个消费者消费 10 个消息,是有一定可能 handleMsg2 一个都消费不到。

b、直连交换机

DirectRabbitConfig:
在这里插入图片描述
在这里插入图片描述

DirectConsumer:
在这里插入图片描述
生产者(生产者这里也要有 DirectRabbitConfig。下同):
在这里插入图片描述

2、扇形交换机

FanoutRabbitConfig:
在这里插入图片描述
在这里插入图片描述
FanoutConsumer:
在这里插入图片描述
生产者:
在这里插入图片描述

3、主题交换机

TopicRabbitConfig:
在这里插入图片描述
在这里插入图片描述
TopicConsumer:
在这里插入图片描述
生产者:
在这里插入图片描述
效果:
在这里插入图片描述

4、Header 交换机

HeaderRabbitConfig:
在这里插入图片描述在这里插入图片描述
HeaderConsumer:
在这里插入图片描述
生产者:
在这里插入图片描述

二、RPC调用

RPC 也称为跨进程调用。也可以理解为一个应用程序调用另外一个应用程序。

1、引言和介绍

在这里插入图片描述

2、架构图

在这里插入图片描述

3、前期准备

跟前面一样,创建生产者和消费者。

消费者:
在这里插入图片描述
生产者:
在这里插入图片描述

4、代码实现

a、消费者

RabbitConfig:
在这里插入图片描述
在这里插入图片描述
HelloController(应该是写在 service 层的,这里直接写在了 controller 层):
在这里插入图片描述

b、生产者

RabbitConfig :
在这里插入图片描述
HelloController:
在这里插入图片描述

三、消息有效期和死信队列

1、默认情况

在这里插入图片描述

2、TTL(Time-To-Live)

TTL(Time-To-Live),消息存活的时间,即消息的有效期。如果我们希望消息能够有一个存活时间,那么我们可以通过设置 TTL 来实现这一需求。如果消息的存活时间超过了 TTL 并且还没有被消息,此时消息就会变成 死信 ,关于 死信 以及 死信队列 ,后面再介绍。

TTL 的设置有两种不同的方式:

  1. 在声明队列的时候,我们可以在队列属性中设置消息的有效期,这样所有进入该队列的消息都会有一个相同的有效期。
  2. 在发送消息的时候设置消息的有效期,这样不同的消息就具有不同的有效期。那如果两个都设置了呢?

以时间短的为准。

在这里插入图片描述

3、单条消息过期

a、前期准备

在这里插入图片描述

单个消息的过期时间:在发消息的时候给消息设置一个过期时间,如果时间到了,这个消息还没有被消费,那么这个消息会自动消失;这个消息没有被删除,而是进到了死信队列里面去。

b、config 配置文件

在这里插入图片描述
这段配置应该很简单,没啥好解释的,有一个排他性,这里稍微多说两句:
在这里插入图片描述
在这里插入图片描述

c、接口

在这里插入图片描述
到这里,就可以测试了,打开可视化界面,可以看到过一会消息就消失了。

4、特殊情况

在这里插入图片描述

5、死信队列

被删除的消息去哪了?真的被删除了吗?并不是!这就涉及到死信队列了,接下来看看死信队列。

a、死信交换机

在这里插入图片描述
在这里插入图片描述

b、代码实现

配置文件 config:

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

接口跟上面的一样。

死信队列消费者:
在这里插入图片描述

在这里插入图片描述

6、死信队列典型应用

这个死信队列可以做一个非常典型的事情,就是延迟消息队列。

虽然 rabbitMQ 没有延迟消息功能,但是能用死信队列实现。

比如定义了死信队列的消费者,10秒钟后消息没有被消费,进入到死信队列中,才被消费掉,那么这不正是一种延迟消息队列吗?

比如典型的应用就是电商网站,下单后 30 分钟内必须付款,不然就会取消订单。虽然可以用定时任务去监控,但是不好维护,出错了不好处理。如果用这种方式,不仅维护方便,也很稳定,出错了还能自动重试。

四、延迟队列第一种方式

延迟队列有两种实现方式,这里讲第一种,第二种在下篇博客中讲解。

1、什么时候需要延迟队列

在这里插入图片描述

2、延迟队列实现思路一(死信队列)

延迟队列实现的思路也很简单,就是上面的 死信队列: DLX(死信交换机)+TTL(消息超时时间)。

我们可以把死信队列就当成延迟队列。

具体来说是这样:

假如一条消息需要延迟 30 分钟执行,我们就设置这条消息的有效期为 30 分钟,同时为这条消息配置死信交换机和死信 routing_key ,并且不为这个消息队列设置消费者,那么 30 分钟后,这条消息由于没有被消费者消费而进入死信队列,此时我们有一个消费者就在“蹲点”这个死信队列,消息一进入死信队列,就立马被消费了。

这就是延迟队列的实现思路,是不是很简单?

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值