RabbitMQ的消息可靠投递 --中篇

前言

上一节提到的问题,关于在消费端消费了消息后进行回调处理作出应答的机制,再通过RPC的方式进行调用生产端把没有正常消费的消息进行重复的投递的过程,产生的疑问都归结于,broker没有及时的作出回应的情况如何处理的问题,而本节就针对这个生产端以及broker端的应答作出详细的解说,结合上一节的内容作出一个补偿的方案,把项目的优化推进。

broker的确认机制

这个表示生产端发送消息,broker端接收到消息后,会回应,而回应被生产端监听到。
在这里插入图片描述
这里只需要配置channel的设置就可以实现

Channel.confirmSelect();
Channel.addConfirmListener;

生产端的伪代码关键的部分是addConfirmListener的内部类的方法,分别是有应答以及没有应答的动作
在这里插入图片描述

消费端的代码跟上节的基本都一样,但是生产的时候就可以通过注解的方式来实现
在这里插入图片描述

当然,会出现网络问题 ,不管成功还是失败都没有回复,这时候就需要定时任务捉取中间状态的消息进行处理。

Broker的return机制

有些生产的消息不一定都可以到达broker端,这时候就需要return
生产端关键的伪代码,监控不可达的消息,重写匿名内部类里面的方法handleReturn()
在这里插入图片描述
消费端的伪代码,只需正常的绑定队列以及交换机
在这里插入图片描述
路由规则最好是通过管控台确认,看vhost,看exchange,队列的绑定情况等等,没有问题就可以启动程序。
而生产端的return消息设置为mandatory的话就会把路由不到是消息删除,队列不做存储。

自定义消费端

关键的点就是自定义消费者类,这个类继承DefaultConsumer这个类,
在这里插入图片描述
设置签收模式也就是重写handleDelivery()这个方法
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值