540、RabbitMQ详细入门教程系列 -【100%消息投递消费(二)】 2022.08.31

一、Mandatory

交换器不存储消息,所有消息都要路由到队列存储。如果中间过程消息丢失,对于生产者而言不设置的情况下是无法知晓的错误。Mandatory实现与Confirm实现类似,通过增加监控监听Listener实现。前面文章消息与队列进阶详细描述过这个参数监听

1.1 相关操作

当消息到达交换器,但是没有匹配队列路由存储时。若通过Mandatory实现监听处理则需要如下几个处理过程:

  1. 发送消息basicPublish()时将设置mandatory参数为true
  2. 为信道channel增加MandatoryListener监听

1.2 代码示例

  • 首先可以看到因为bindingKey与routingKey不一致,消息不能路由到队列
  • 然后可以看到发送消息时将mandatory参数设置为true表示增加mandatory监听
  • 最后可以看到在信道上增加了ReturnLisrtener监听,取得未路由消息相关参数信息
    在这里插入图片描述

1.3 参数详解

ReturnListener中仅仅包含唯一方法handleReturn(),该方法中含有系列参数,参数含义如下表所示:
在这里插入图片描述

二、备用交换器

Mandatory增加的ReturnListener监听需要在发送消息代码中增加逻辑,这对于追求功能专一性而言不是好消息。通过RabbitMQ也根本检测不到这段逻辑,也不利于后续代码维护。所以提出备用交换器,创建交换器时绑定,当交换器消息未找到路由队列时消息将转发到备用交换器

2.1 相关操作

备用交换器其原理类似于交换器与交换器绑定,需要注意以下几点:

  1. 创建交换器时使用Map参数绑定备用交换器
  2. 备用交换器接收路由到的消息不会更改任何属性,包括routingKey
  3. 可以将备用交换器设置为内置交换器

2.2 代码示例

通过参数Map绑定备用交换器,验证效果将消息发送路由键routingKey设置为备用交换器路由键。可以查看备用交换器创建时的第五个参数,上面也提到最优设置为内置交换器,属性internal

2.3 测试结果

最后显示备用交换器中有一条消息,证明结果的正确性。备用交换器可以用作消息不能正确路由时的一种解决方案
在这里插入图片描述

三、队列与消息持久化

这个问题在前面相关队列与队列消息的文章中已经详细讲解,为了整个消息投递可靠性的完整,这里再次描述一下队列与队列消息的持久化。注意以点:
单独的队列消息持久化并不能实现消息持久化,同理单独的队列持久化也不能实现消息持久化。需要队列与队列消息同时持久化方可

3.1 队列持久化

持久化即将队列信息写入磁盘持久化保存,当RabbitMQ应用服务故障宕机重启时可以自动进行数据恢复的操作称之为队列持久化。实现只需要在创建队列时将持久化参数设置为true即可,如下所示:

在这里插入图片描述
进入RabbitMQ应用的WEB页面控制台查看该队列标志D,表示持久化。如下所示:

在这里插入图片描述

  • 发送消息方法参数列表要求传递BasicProperties,该类使用建造者模式设计,其中deliveryMod表示消息持久化。1 默认值不进行持久化,2 将消息持久化写入磁盘
  • MessageProperties类封装常用系列BasicProperties对象,可以直接使用

3.2 总结

队列持久化 + 队列消息持久化 = 完整持久化,持久化对RabbitMQ应用的性能是一种负担,可以根据数据类型进行范围数据持久化。如订单数据、支付数据等等较为重要的数据可以采用持久化的操作尽量避免消息丢失

四、消费者确认

生产者消息已经投递并路由到队列存储,当消费者消费时消费应用宕机导致消费逻辑不完整的宕机也是保证消息百分百投递消费的关键一环。RabbitMQ针对这一点提供消费者确认机制,配置该特性后,当且仅当消费者确认以后RabbitMQ应用才会删除消息
讲解RabbitMQ消费者确认机制前需要确认默认情况下消费者将自动确认,也就是当消息从RabbitMQ应用服务取出时将被删除,这也是诱发消息丢失的原因。所以为了实现后续手动控制消息确认的逻辑,消费消息时就需要将参数autoAck设置为false
在这里插入图片描述

4.1 basicAck

消息确认,参数包含deliveryTag、multiple。作用与生产者确认Confirm一致:

  • deliveryTag:RabbitMQ应用会为每条消息产生唯一编号,生产者亦或是消费者都需要根据编码进行相关消息操作
  • multiple:批量操作,即将编码小于本次操作编码的消息都进行本次一致的操作

4.2 消息拒绝

消息拒绝有两个API,basicReject()与basicNack(),两者唯一的差距在于前者不能进行multiple的批量操作。两者共同含有以下两个参数属性:

  • deliveryTag:RabbitMQ应用会为每条消息产生唯一编号,生产者亦或是消费者都需要根据编码进行相关消息操作
  • requeue:是否重新放回队列,这里抛弃的消息如果设置了死信转发,将会被路由到配置的死信交换器

五、参考链接

[01] RabbitMQ详细入门教程系列 -【100%消息投递消费(二)】

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值