消息队列-RabbitMQ-消息确认机制

为了保证消息的不丢失,可靠抵达,可以使用事务消息,但是性能会下降250倍,为此引入确认机制。

1.ConfirmCallBack

服务器收到消息就回调

● 被broker接收到只能表示Message已经到达服务器,并不能保证消息一定会投递到目标queue里面

● 消息只要被broker接收就会执行confirmCallBack(定制RabbitTemplate),如果是cluster模式,需要所有的broker都接收到才会调用confirmCallBack

● 在配置文件中加入:

yaml 复制代码
spring.rabbitmq.publisher-confirms=true

在创建 connectionFactory 的时候设置 PublisherConfirms (true) 选项,开启 ConfirmCallback ,因此我们可以定制 RabbitTemplate ,在 config 包下,创建 MyRabbitConfig 配置类,设置确认回调,需要编写如下方法

java 复制代码
//设置确认回调
rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {

    /**
     *
     * 1、只要消息抵达Broker就ack=true
     * @param correlationData 当前消息的唯一关联数据(这个是消息的唯一id)
     * @param ack  消息是否成功收到
     * @param cause 失败的原因
     */
    @Override
    public void confirm(CorrelationData correlationData, boolean ack, String cause) {

        /**
         * 1、做好消息确认机制(pulisher,consumer【手动ack】)
         * 2、每一个发送的消息都在数据库做好记录。定期将失败的消息再次发送一遍
         */
        //服务器收到了;
        //修改消息的状态
        System.out.println("confirm...correlationData["+correlationData+"]==>ack["+ack+"]==>cause["+cause+"]");
    }
});

2. ReturnCallback

消息抵达队列进行回调

1、在 application.properties 中进行配置:

yaml 复制代码
spring.rabbitmq.publisher-returns=true
spring.rabbitmq.template.mandatory=true

2、设置确认回调ReturnCallback

java 复制代码
//设置消息抵达队列的确认回调
rabbitTemplate.setReturnCallback(new RabbitTemplate.ReturnCallback() {
    /**
     * 只要消息没有投递给指定的队列,就触发这个失败回调(只有失败才会回调???)
     * @param message   投递失败的消息详细信息
     * @param replyCode 回复的状态码
     * @param replyText 回复的文本内容
     * @param exchange  当时这个消息发给哪个交换机
     * @param routingKey 当时这个消息用哪个路由键
     */
    @Override
    public void returnedMessage(Message message, int replyCode, String replyText, String exchange, String routingKey) {
        //报错误了。修改数据库当前消息的状态->错误。
        System.out.println("Fail Message["+message+"]==>replyCode["+replyCode+"]==>replyText["+replyText+"]===>exchange["+exchange+"]===>routingKey["+routingKey+"]");
    }
});

3.Ack消息确认机制

  • 消费者获取到消息,成功处理,可以回复 Ack 给 Broker
  • basic.ack 用于肯定确认,broker 将移除此消息
  • basic.nack 用于否定确认,可以指定 broker 是否丢弃此消息,可以批量
  • basic.reject 用于否定确认,同上,但不能批量
  • 默认自动ack,消息被消费者收到,就会从broker的queue中移除
相关推荐
徐先生 @_@|||16 分钟前
数据分析体系全览导图综述
大数据·hadoop·分布式·数据分析
虹科网络安全1 小时前
艾体宝洞察 | 缓存策略深度解析:从内存缓存到 Redis 分布式缓存
redis·分布式·缓存
廋到被风吹走4 小时前
【消息队列】选型深度对比:Kafka vs RocketMQ vs RabbitMQ
kafka·rabbitmq·rocketmq
YE1234567_4 小时前
从底层零拷贝到分布式架构:深度剖析现代 C++ 构建超大规模高性能 AI 插件引擎的实战之道
c++·分布式·架构
笃行客从不躺平4 小时前
Seata + AT 模式 复习记录
java·分布式
洛阳纸贵5 小时前
JAVA高级工程师-消息中间件RabbitMQ工作模式(二)
java·rabbitmq·java-rabbitmq
像少年啦飞驰点、5 小时前
Java大厂面试真题:Spring Boot + Kafka + Redis 在电商场景下的实战应用
java·spring boot·redis·分布式·kafka·面试题·电商秒杀
徐先生 @_@|||6 小时前
基于Spark配置+缓存策略+Junpyter Notebook 实现Spark数据加速调试
大数据·分布式·缓存·spark
小北方城市网6 小时前
微服务接口熔断降级与限流实战:保障系统高可用
java·spring boot·python·rabbitmq·java-rabbitmq·数据库架构
无心水6 小时前
【分布式利器:腾讯TSF】11、腾讯TSF微服务框架深度对比:全面解析TSF vs Spring Cloud vs Dubbo vs Service Mesh
分布式·spring cloud·微服务·dubbo·springcloud·service mesh·分布式利器