【初始RabbitMQ】发布订阅的实现

这篇具有很好参考价值的文章主要介绍了【初始RabbitMQ】发布订阅的实现。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

发布确认原理

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

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

简单的来说发布确认的作用就是防止数据丢失

【初始RabbitMQ】发布订阅的实现,消息队列,java,消息队列,分布式

发布确认的策略 

开启发布确认的方法

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

【初始RabbitMQ】发布订阅的实现,消息队列,java,消息队列,分布式

单个确认发布

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

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

public static void publicMessageIndividually() throws IOException, InterruptedException {
        Channel channel = RabbitMqUtils.getChannel();
        String queueName = UUID.randomUUID().toString();
        /*
         *生成一个队列
         * 1.队列名称
         * 2.队列里面的信息是否持久化(磁盘)默认情况时在内存
         * 3.该队列是否只供一个消费者进行消费 是否消费共享 true是允许
         * 4.是否自动删除 最后一个消费者断开连接之后 该队列是否自动删除 true自动删除 false不自动删除
         * 5.其他参数 延迟消息等
         */
        channel.queueDeclare(queueName,false,false,false,null);
        //开启发布确认
        channel.confirmSelect();
        long begin = System.currentTimeMillis();
        for (int i = 0; i < MESSAGE_COUNT; i++) {
            String message = i + "";
            channel.basicPublish("",queueName,null,message.getBytes(StandardCharsets.UTF_8));
            //服务器返回false或超时内未返回,生产者可以消息重新发送
            boolean flag = channel.waitForConfirms();
            if(flag){
                System.out.println("消息发布成功!");
            }
        }
        long end = System.currentTimeMillis();
        System.out.println("发布" + MESSAGE_COUNT + "个单独确认消息,耗时" + (end - begin) + "ms");
    }

批量确认发布

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

    public static void publishMessageBatch() throws IOException, InterruptedException {
        Channel channel = RabbitMqUtils.getChannel();
        String queueName = UUID.randomUUID().toString();
        channel.queueDeclare(queueName,false,false,false,null);
        //开启发布确认
        channel.confirmSelect();
        //批量确认消息大小
        int batchSize = 100;
        //未确定消息
        int outstandingMessageCount = 0;
        long begin = System.currentTimeMillis();
        for (int i = 0; i < MESSAGE_COUNT; i++) {
            String message = i+"";
            channel.basicPublish("",queueName,null,message.getBytes(StandardCharsets.UTF_8));
            outstandingMessageCount++;
            if(outstandingMessageCount==batchSize){
                channel.waitForConfirms();
                outstandingMessageCount=0;
            }
        }
        if(outstandingMessageCount>0){
            channel.waitForConfirms();
        }
        long end = System.currentTimeMillis();
        System.out.println("发布" + MESSAGE_COUNT + "个批量确认消息,耗时" + (end - begin) + "ms");
    }

异步确认发布

异步确认发布通常指的是在消息发布过程中,消息的生产者(或发送方)在发送消息后,不需要等待消息被消费者(或接收方)确认接收,而是可以继续进行其他操作。这种异步确认的机制可以提高系统的并发性和效率

在具体实现上,异步确认发布通常涉及到以下几个步骤:

  1. 消息生产者将消息发送到消息队列或中间件中
  2. 消息队列或中间件在接收到消息后,会为每条消息分配一个唯一的序列号或ID
  3. 消息队列或中间件将消息投递到相应的消费者队列中
  4. 消费者从自己的消费者队列中拉取消息并进行处理
  5. 消费者在处理完消息后,会向消息队列或中间件发送一个确认消息,表示该消息已经被成功处理
  6. 消息队列或中间件在接收到消费者的确认消息后,会将该确认消息与原始消息的序列号或ID进行匹配,确认该消息已经被成功处理
  7. 消息队列或中间件会向消息生产者发送一个异步确认消息,通知消息生产者该消息已经被成功处理

【初始RabbitMQ】发布订阅的实现,消息队列,java,消息队列,分布式

 

public static void publishMessageAsync() throws IOException {
        Channel channel = RabbitMqUtils.getChannel();
        String queueName = UUID.randomUUID().toString();
        channel.queueDeclare(queueName,false,false,false,null);
        //开启发布确定
        channel.confirmSelect();
        /**
         * 线程安全有序的一个哈希表,适合用于高并发情况
         * 1、轻松将序号和消息进行关联
         * 2、轻松批量删除条目 只需要给到序列号
         * 3、支持高并发访问
         */
        ConcurrentSkipListMap<Long,String> outstandingConfirms = new ConcurrentSkipListMap<>();
        //开始时间
        long begin = System.currentTimeMillis();
        ConfirmCallback ackCallback = (deliveryTag,multiple)->{
            //是否是批量处理
            if(multiple){
                //返回的是小于等于(如果是小于等于需要在参数中加true)当前序列号的未确认消息 是一个 map
                ConcurrentNavigableMap<Long, String> confirmed = outstandingConfirms.headMap(deliveryTag,true);
                confirmed.clear();
            }else{
                //只清除当前序列号的消息
                outstandingConfirms.remove(deliveryTag);
            }
            System.out.println("确认消息"+deliveryTag);
        };
        ConfirmCallback nackCallback = (deliveryTag,multiple)->{
            String message = outstandingConfirms.get(deliveryTag);
            System.out.println("发布的消息"+message+"未被确认,序列号"+deliveryTag);
           // System.out.println("未确认消息"+deliveryTag);
        };
        //准备消息的监听器 监听哪些消息成功 哪些消息失效
        channel.addConfirmListener(ackCallback,nackCallback);
        //批量发送消息
        for (int i = 0; i < MESSAGE_COUNT; i++) {
            String message = "消息"+i;
            /**
             * channel.getNextPublishSeqNo()获取下一个消息的序列号
             * 通过序列号与消息体进行一个关联
             * 全部都是未确认的消息体
             */
            outstandingConfirms.put(channel.getNextPublishSeqNo(),message);
            channel.basicPublish("",queueName,null,message.getBytes(StandardCharsets.UTF_8));
        }
        long end = System.currentTimeMillis();
        System.out.println("发布" + MESSAGE_COUNT + "个批量确认消息,耗时" + (end - begin) + "ms");
    }

以上 3 种发布确认速度对比

单独发布消息:同步等待确认,简单,但吞吐量非常有限

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

异步处理: 最佳性能和资源使用,在出现错误的情况下可以很好地控制,但是实现起来稍微难些文章来源地址https://www.toymoban.com/news/detail-834935.html

花费时间对比

    public static void main(String[] args) throws IOException, InterruptedException {
        //单个确认发布
        ConfirmMessage.publicMessageIndividually();//发布1000个单独确认消息,耗时47298ms
        //批量确认发布
        ConfirmMessage.publishMessageBatch();//发布1000个批量确认消息,耗时866ms
        //异步确认发布
        ConfirmMessage.publishMessageAsync();//发布1000个批量确认消息,耗时104ms
    }

到了这里,关于【初始RabbitMQ】发布订阅的实现的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【新星计划】Kafka分布式发布订阅消息系统

      目录 Kafka分布式发布订阅消息系统 1. 概述 1.1 点对点消息传递模式 1.2 发布-订阅消息传递模式 1.3 Kafka特点 1.4 kafka拓扑图 2. Kafka工作原理 2.1 Kafka核心组件介绍 2.2 Kafka工作流程分析 2.2.1 生产者生产消息过程 2.2.2 消费者消费消息过程 2.2.3 Kafka Topics 2.2.4 Kafka Partition 2.2.4 Kafka

    2024年02月08日
    浏览(44)
  • .Net6 记一次RabbitMq消息订阅/发布优化

             首先介绍一下项目情况,项目需要设备在线实时采集,最高采集频率为1次/秒,设备上传数据时,协议规定的是10条/包,服务端通过rabbitMq接收消息,并进行存储、预警、推送等进行多层处理,因为web端要求数据实时展示,且延时不得超过1分钟,因数据量较大,

    2024年01月18日
    浏览(46)
  • RabbitMQ学习——发布订阅/fanout模式 & topic模式 & rabbitmq回调确认 & 延迟队列(死信)设计

    1.rabbitmq队列方式的梳理,点对点,一对多; 2.发布订阅模式,交换机到消费者,以邮箱和手机验证码为例; 3.topic模式,根据规则决定发送给哪个队列; 4.rabbitmq回调确认,setConfirmCallback和setReturnsCallback; 5.死信队列,延迟队列,创建方法,正常—死信,设置延迟时间; 点对

    2024年02月13日
    浏览(73)
  • RabbitMQ基础(2)——发布订阅/fanout模式 & topic模式 & rabbitmq回调确认 & 延迟队列(死信)设计

    1.rabbitmq队列方式的梳理,点对点,一对多; 2.发布订阅模式,交换机到消费者,以邮箱和手机验证码为例; 3.topic模式,根据规则决定发送给哪个队列; 4.rabbitmq回调确认,setConfirmCallback和setReturnsCallback; 5.死信队列,延迟队列,创建方法,正常—死信,设置延迟时间; 点对

    2024年02月10日
    浏览(54)
  • RabbitMQ(一) - 基本结构、SpringBoot整合RabbitMQ、工作队列、发布订阅、直接、主题交换机模式

    Publisher : 生产者 Queue: 存储消息的容器队列; Consumer:消费者 Connection:消费者与消息服务的TCP连接 Channel:信道,是TCP里面的虚拟连接。例如:电缆相当于TCP,信道是一条独立光纤束,一条TCP连接上创建多少条信道是没有限制的。TCP一旦打开,就会出AMQP信道。无论是发布消息

    2024年02月14日
    浏览(52)
  • 分布式消息队列:RabbitMQ(1)

    目录 一:中间件 二:分布式消息队列  2.1:是消息队列 2.1.1:消息队列的优势 2.1.1.1:异步处理化 2.1.1.2:削峰填谷 2.2:分布式消息队列 2.2.1:分布式消息队列的优势 2.2.1.1:数据的持久化 2.2.1.2:可扩展性 2.2.1.3:应用解耦 2.2.1.4:发送订阅  2.2.2:分布式消息队列的应用场景  三:Rabbitmq 3.1:基

    2024年02月08日
    浏览(63)
  • 分布式消息队列:Rabbitmq(2)

    目录 一:交换机 1:Direct交换机 1.1生产者端代码:  1.2:消费者端代码: 2:Topic主题交换机  2.1:生产者代码:  2.2:消费者代码:  二:核心特性 2.1:消息过期机制 2.1.1:给队列中的全部消息指定过期时间 2.1.2:给某条消息指定过期时间  2.2:死信队列 绑定: 让交换机和队列进行关联,可以指

    2024年02月08日
    浏览(42)
  • Spring Boot进阶(62):Redis魔法:用发布订阅功能打造高效消息队列!

            话说,玩过MQ的同学可能都知道【发布订阅】模式,不就是一种消息传递方式嘛;如果没玩过,那也不打紧,下文我会简单做个科普。但是对于Redis如何实现MQ的【发布订阅】功能?这才是问题的关键,有的同学就说“压根没玩过呀!不造” ,哈哈,bug菌既然敢写便有

    2024年02月09日
    浏览(45)
  • 【Java】微服务——RabbitMQ消息队列(SpringAMQP实现五种消息模型)

    微服务间通讯有同步和异步两种方式: 同步通讯:就像打电话,需要实时响应。 异步通讯:就像发邮件,不需要马上回复。 两种方式各有优劣,打电话可以立即得到响应,但是你却不能跟多个人同时通话。发送邮件可以同时与多个人收发邮件,但是往往响应会有延迟。 1.

    2024年02月08日
    浏览(60)
  • 消息队列-RabbitMQ:发布确认—发布确认逻辑和发布确认的策略

    生产者将信道设置成 confirm 模式,一旦信道进入 confirm 模式,所有在该信道上面发布的消息都将会被指派一个唯一的 ID (从 1 开始),一旦消息被投递到所有匹配的队列之后,broker 就会发送一个确认给生产者 (包含消息的唯一 ID),这就使得生产者知道消息已经正确到达目的队列

    2024年02月21日
    浏览(37)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包