前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >MQ发布确认

MQ发布确认

作者头像
一个风轻云淡
发布于 2022-11-13 03:16:36
发布于 2022-11-13 03:16:36
1.2K00
代码可运行
举报
文章被收录于专栏:java学习javajava学习java
运行总次数:0
代码可运行

发布确认原理

  生产者将信道设置成confirm模式,一旦信道进入confirm模式,所有在该信道上面发布的消息都将会被指派一个唯一的ID(从1开始),一旦消息被投递到所有匹配的队列之后,broker就会发送一个确认给生产者(包含消息的唯一ID),这就使得生产者知道消息已经正确到达目的队列了,如果消息和队列是可持久化的,那么确认消息会在将消息写入磁盘之后发出,broker回传给生产者的确认消息中delivery-tag域包含了确认消息的序列号,此外broker也可以设置basic.ack的multiple域,表示到这个序列号之前的所有消息都已经得到了处理。

confirm模式最大的好处在于他是异步的,一旦发布一条消息,生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息,当消息最终得到确认之后,生产者应用便可以通过回调方法来处理该确认消息,如果RabbitMQ因为自身内部错误导致消息丢失,就会发送一条nack消息,生产者应用程序同样可以在回调方法中处理该nack消息 

发布确认的策略  

 开启发布确认的方法

发布确认默认是没有开启的,如果要开启需要调用方法confirmSelect,每当你要想使用发布确认,都需要在channel上调用该方法 

单个确认发布

这是一种简单的确认方式,它是一种同步确认发布的方式也就是发布一个消息之后只有它被确认发布,后续的消息才能继续发布,waitForConfirmsOrDie(long)这个方法只有在消息被确认的时候才返回,如果在指定时间范围内这个消息没有被确认那么它将抛出异常。

这种确认方式有一个最大的缺点就是:发布速度特别的慢,因为如果没有确认发布的消息就会阻塞所有后续消息的发布,这种方式最多提供每秒不超过数百条发布消息的吞吐量。当然对于某些应用程序来说这可能已经足够了。

代码实现:工具类获取信道

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public class untils {
    public static Channel getChannel() throws IOException, TimeoutException {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost("192.168.231.132");
        factory.setUsername("admin");
        factory.setPassword("123");
        Connection connection = factory.newConnection();
        Channel channel = connection.createChannel();
        return channel;
    }
}

实现: 

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
 public static  void publishMessageIndivdually()throws Exception{
        String quequeName= UUID.randomUUID().toString();
        Channel channel = untils.getChannel();
        //开启发布确认
        channel.confirmSelect();
        long begin=System.currentTimeMillis();
        for(int i=0;i<1000;i++)
        {
            String message=i+"";
            channel.basicPublish("",quequeName,null,message.getBytes(StandardCharsets.UTF_8));
            //服务端返回false或者超时时间内未返回,生产者可以消息重发
            boolean flag=channel.waitForConfirms();
//            if(flag)
//            {
//                System.out.println("消息发送成功");
//            }
        }
        long end=System.currentTimeMillis();
        System.out.println("发布"+1000+"个单独确认的消息,耗时"+(end-begin)+"ms");
    }

批量确认发布

上面那种方式非常慢,与单个等待确认消息相比,先发布一批消息然后一起确认可以极大地提高吞吐量,当然这种方式的缺点就是:当发生故障导致发布出现问题时,不知道是哪个消息出现问题了,我们必须将整个批处理保存在内存中,以记录重要的信息而后重新发布消息。当然这种方案仍然是同步的,也一样阻塞消息的发布

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public static  void publishMessageBatch()throws  Exception{
        String quequeName= UUID.randomUUID().toString();
        Channel channel = untils.getChannel();
        //开启发布确认
        channel.confirmSelect();
        //批量确认消息大小
        int batchSize = 100;
        // 未确认消息个数
        int outstandingMessageCount = 0;
        long begin=System.currentTimeMillis();
        for(int i=0;i<1000;i++)
        {
            String message=i+"";
            channel.basicPublish("",quequeName,null,message.getBytes(StandardCharsets.UTF_8));
            outstandingMessageCount++;
            if(outstandingMessageCount==batchSize)
            {
                channel.waitForConfirms();
                outstandingMessageCount=0;
            }
        }
        long end=System.currentTimeMillis();
        System.out.println("发布"+"1000个批量确认的消息,耗时"+(end-begin)+"ms");
    }

异步确认发布

异步确认虽然编程逻辑比上两个要复杂,但是性价比最高,无论是可靠性还是效率都没得说,他是利用回调函数来达到消息可靠性传递的,这个中间件也是通过函数回调来保证是否投递成功,下面就让我们来详细讲解异步确认是怎么实现的。

如何处理异步未确认消息

最好的解决的解决方案就是把未确认的消息放到一个基于内存的能被发布线程访问的队列,比如说用ConcurrentLinkedQueue这个队列在confirm callbacks与发布线程之间进行消息的传递。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public static void publishMessaheAsync()throws  Exception{
        String quequeName= UUID.randomUUID().toString();
        Channel channel = untils.getChannel();
        channel.queueDeclare(quequeName,false,false,false,null);
        //开启发布确认
        channel.confirmSelect();
        /**
         * 线程安全有序的一个哈希表,适合高并发的情况
         *1.轻松的将序号与消息进行关联
         * 2.轻松的批量的删除条目,只要给到序列号
         * 3.支持并发的访问
         */
        ConcurrentSkipListMap<Long,String> outstandingConfirms=new ConcurrentSkipListMap<>();
        /**
         * 确认到消息的一个回调
         * 1.消息的序列号
         * 2.true可以确认小于等于当前序列号的消息
         * false确认当前序列号的消息
         */
        ConfirmCallback ackCallback=(sequenceNumber,multiple)->{
            if(multiple)
            {
                //返回的是小于等于当前序列号未确认的消息,是一个map
                ConcurrentNavigableMap<Long, String> confirmed = outstandingConfirms.headMap(sequenceNumber, true);
                //消除该部分未确认的消息
                confirmed.clear();
            }
            else
            {
                //只清楚当前序列号的消息
                outstandingConfirms.remove(sequenceNumber);
            }
        };
        ConfirmCallback nackCallback=(sequenceNumber,multiple)->{
            String message=outstandingConfirms.get(sequenceNumber);
            System.out.println("发布消息"+message+"未被确认,序列号"+sequenceNumber);
        };
        /**
         * 添加一个异步确认的监听器
         * 1.确认收到消息的回调
         * 2.未收到消息的回调
         */
        channel.addConfirmListener(ackCallback,nackCallback);
        long begin=System.currentTimeMillis();
        for(int i=0;i<1000;i++)
        {
            String message="消息"+i;
            /**
             * channel.getNextPublishSeqNo()获取下一个消息的序列号
             * 全部都是未确认的消息体
             */
             outstandingConfirms.put(channel.getNextPublishSeqNo(),message);
             channel.basicPublish("",quequeName,null,message.getBytes(StandardCharsets.UTF_8));
        }
        long end=System.currentTimeMillis();
        System.out.println("发布1000个异步确认的消息,耗时"+(end-begin)+"ms");
    }

结果:

单独发布消息

同步等待确认,简单,但吞吐量非常有限。

批量发布消息

批量同步等待确认,简单,合理的吞吐量,一旦出现问题但很难推断出是那条 消息出现了问题。

异步处理

最佳性能和资源使用,在出现错误的情况下可以很好地控制,但是实现起来稍微难些 

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2022-07-20,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
RibbitMQ学习笔记之MQ发布确认
生产者将信道设置成 confirm 模式,一旦信道进入 confirm 模式,**所有在该信道上面发布的消息都将会被指派一个唯一的 ID( 从 1 开始),**一旦消息被投递到所有匹配的队列之后,broker 就会发送一个确认给生产者(包含消息的唯一 ID),这就使得生产者知道消息已经正确到达目的队列了,如果消息和队列是可持久化的,那么确认消息会在将消息写入磁盘之后发出,broker 回传给生产者的确认消息中 delivery-tag 域包含了确认消息的序列号,此外 broker 也可以设置basic.ack 的 multiple 域,表示到这个序列号之前的所有消息都已经得到了处理。
默 语
2024/11/20
770
RibbitMQ学习笔记之MQ发布确认
RabbitMQ发布确认详解
小熊学Java
2023/07/16
2480
RabbitMQ发布确认详解
RabbitMQ发布确认
  生产者将信道设置成 confirm 模式,一旦信道进入 confirm 模式,所有在该信道上面发布的消息都将会被指派一个唯一的 ID(从 1 开始),一旦消息被投递到所有匹配的队列之后,broker就会发送一个确认给生产者(包含消息的唯一 ID),这就使得生产者知道消息已经正确到达目的队列了,如果消息和队列是可持久化的,那么确认消息会在将消息写入磁盘之后发出,broker 回传给生产者的确认消息中 delivery-tag 域包含了确认消息的序列号,此外 broker 也可以设置basic.ack 的 multiple 域,表示到这个序列号之前的所有消息都已经得到了处理。   confirm 模式最大的好处在于他是异步的,一旦发布一条消息,生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息,当消息最终得到确认之后,生产者应用便可以通过回调方法来处理该确认消息,如果 RabbitMQ 因为自身内部错误导致消息丢失,就会发送一条 nack 消息,生产者应用程序同样可以在回调方法中处理该 nack 消息。
别团等shy哥发育
2023/02/25
7150
RabbitMQ发布确认
RabbitMQ 学习(七)----发布确认
  保证生产者将信息成功的发送到 RabbitMQ的 server端了,那么broker就会回一个确认,如果没有收到或者收到拒绝信息,那么说明可能网络不好没有发送成功,server端宕机了,broker拒绝接收等情况,如果不进行后续处理,那么信息就会丢失,生产者收到失败的消息使用回调函数在进行处理。
RAIN7
2022/10/07
5120
RabbitMQ 学习(七)----发布确认
RabbitMQ 消息应答与发布
消费者完成一个任务可能需要一段时间,如果其中一个消费者处理一个长的任务并仅只完成了部分突然它挂掉了,会发生什么情况。RabbitMQ 一旦向消费者传递了一条消息,便立即将该消息标记为删除。在这种情况下,突然有个消费者挂掉了,我们将丢失正在处理的消息。以及后续发送给该消费者的消息,因为它无法接收到。
用户9615083
2022/12/25
4550
RabbitMQ 消息应答与发布
RabbitMQ之消息应答与发布确认
生产者发布消息到 RabbitMQ 后,需要 RabbitMQ 返回「ACK(已收到)」给生产者,这样生产者才知道自己生产的消息成功发布出去。
shaoshaossm
2022/12/27
5740
RabbitMQ之消息应答与发布确认
消息队列RabbitMQ核心:简单(Hello World)模式、队列(Work Queues)模式、发布订阅模式
消息队列RabbitMQ提供了六种工作模式:简单模式、work queues、发布订阅模式、路由模式、主题模式、发布确认模式。本文将介绍前三种工作模式。所有的案例代码都是使用Java语言实现。
百思不得小赵
2022/12/07
5840
消息队列RabbitMQ核心:简单(Hello World)模式、队列(Work Queues)模式、发布订阅模式
RabbitMq 笔记,一篇文章入门
默认的端口15672:rabbitmq管理平台端口号 默认的端口5672: rabbitmq消息中间内部通讯的端口 默认的端口号25672 rabbitmq集群的端口号
一写代码就开心
2022/05/09
7710
RabbitMq 笔记,一篇文章入门
【RabbitMQ】发布确认机制的具体实现
发送确认机制最大的好处在于它是异步的,生产者可以同时发布消息和等待信道返回确认消息
椰椰椰耶
2025/05/15
800
【RabbitMQ】发布确认机制的具体实现
RabbitMQ---消息队列---上半部分
MQ(message queue),从字面意思上看,本质是个队列,FIFO 先入先出,只不过队列中存放的内容是message 而已,还是一种跨进程的通信机制,用于上下游传递消息。在互联网架构中,MQ 是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了 MQ 之后,消息发送上游只需要依赖 MQ,不用依赖其他服务。
大忽悠爱学习
2021/12/07
1.1K0
RabbitMQ---消息队列---上半部分
RabbitMQ
​ MQ(message queue),从字面意思上看,本质是个队列,FIFO 先入先出,只不过队列中存放的内容是 message 而已,还是一种跨进程的通信机制,用于上下游传递消息。在互联网架构中,MQ 是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了 MQ 之后,消息发送上游只需要依赖 MQ,不用依赖其他服务。
OY
2022/03/21
1.8K0
RabbitMQ
RabbitMQ 超详细入门篇
本人使用的是 阿里云服务器 没有的话也可以使用虚拟机… 事先使用连接工具上传了文件
Java_慈祥
2024/08/06
2.6K0
RabbitMQ 超详细入门篇
RabbitMQ
RabbitMQ属于中间件的一种,其实很多东西都是中间件比如说mysql redis都是的 其实中间件是一种概念,只要是实现软件和软件之间沟通连接的软件都可以叫做中间件
xiaozhangStu
2023/05/04
1.1K0
RabbitMQ 七种工作模式介绍
RabbitMQ 共提供了7种⼯作模式供我们进⾏消息传递,接下来一一介绍它的实现与目的
用户11369558
2024/11/20
1170
RabbitMQ 七种工作模式介绍
RabbitMQ如何保证消息99.99%被发送成功?
要想保证消息不丢失,首先我们得保证生产者能成功的将消息发送到RabbitMQ服务器。
Java_老男孩
2019/06/06
1K0
RabbitMQ发布确认
RabbitMQ的发布确认(Publish Confirm)是一种机制,用于确保消息在发送到RabbitMQ之后被成功接收和持久化。通过使用发布确认,生产者可以获得对消息的可靠性保证,避免消息丢失。
堕落飞鸟
2023/05/16
7070
爆肝3万字,为你吃透RabbitMQ,最详细的RabbitMQ讲解(VIP典藏版)
早在之前就了解到了消息中间件,但是一直没有系统的学习,最近花了一段时间系统学习了当下最为主流的 RabbitMQ 消息队列,学习过程中也随时记录,刚开始学习的时候懵懵懂懂,做的笔记都比较杂乱,系统学习完后我将笔记内容不断反复修改,对章节进行设计调整,最终整合出了以下好理解、案例多、超详细的 RabbitMQ 学习笔记,希望能帮到大家~
SmallRoll小卷
2023/03/05
12.3K0
爆肝3万字,为你吃透RabbitMQ,最详细的RabbitMQ讲解(VIP典藏版)
四种途径提高RabbitMQ传输数据的可靠性(二)
针对问题(1),我们可以通过生产者的确认消息机制来解决,主要分为两种:第一是事务机制、第二是发送方确认机制
java架构师
2019/03/08
5650
四种途径提高RabbitMQ传输数据的可靠性(二)
【消息队列之rabbitmq】Rabbitmq之消息可靠性投递和ACK机制实战
上篇文章介绍了rabbitmq的基本知识、交换机类型实战《【消息队列之rabbitmq】学习RabbitMQ必备品之一》 这篇文章主要围绕着消息确认机制为中心,展开实战;接触过消息中间件的伙伴都知道,消息会存在以下问题: 1、消息丢失问题和可靠性投递问题; 2、消息如何保证顺序消费; 3、消息如何保证幂等性问题,即重复消费问题等等… 本文主要以Rabbitmq消息中间件解决问题一的实践,其他问题小编会重新写文章总结;
沁溪源
2022/01/13
1.3K0
【消息队列之rabbitmq】Rabbitmq之消息可靠性投递和ACK机制实战
RabbitMQ 消息确认机制
消息的确认,是指生产者投递消息后,如果 Broker 收到消息,则会给我们生产者一个应答。生产者进行接收应答,用来确定这条消息是否正常的发送到 Broker ,这种方式也是消息的可靠性投递的核心保障!
海向
2019/09/23
1.1K0
RabbitMQ 消息确认机制
相关推荐
RibbitMQ学习笔记之MQ发布确认
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验