RabbitMQ（三）发布确认1、消息丢失解决2、发布确认原理3、发布确认策略

86 阅读 0 评论 57 点赞

我是靠谱客的博主细心飞鸟，最近开发中收集的这篇文章主要介绍RabbitMQ（三）发布确认1、消息丢失解决2、发布确认原理3、发布确认策略，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

1、消息丢失解决

保证消息不丢失：

生产者发送给MQ的过程中不被丢失：

保证队列持久化
设置队列中要发送的消息持久化--------消息保存在磁盘当中，但由于写入磁盘的过程中无法保证完全写入需要有---消息发布确认
发布确认-----------mq将消息保存到磁盘中，并且通知生产者

消费者使用不丢失：消息自动应答改为手动应答

2、发布确认原理

发布确认机制就是发送方确认模式，生产者在Channel(信道)上调用confirmSelect()方法，请求将Broker的Channel(信道)设置成为confirm模式，一旦信道进入confirm模式，所有在该信道上流通的消息都会被指派一个唯一的ID(从1开始)，并将消息被推送到匹配的队列中。

生产者可以在推送消息之后，通过信道调用waitForConfirms()方法，向RabbitMQ发送消息发布确认请求，RabbitMQ服务器会返回消息发布确认的状态给生产者（包括确认的消息及消息的ID信息），这样生产者就知道消息已经被正确推送到目的队列了。如果收到发布确认失败的消息，生产者可以进行后续的重新发送。

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

3、发布确认策略

3.1开启发布确认的方法

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

          //创建信道
        Channel channel = connection.createChannel();
          //开启发布确认
        channel.confirmSelect();

3.2单个发布确认

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

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

生产者发送一条消息给Broker.
生产者调用waitForConfirms()方法，向Broker发送发布确认请求.
Broker向生产者返回确认发布失败(NACK)的状态，生产者重新发送这一条消息。失败可能是Broker服务端出现问题，导致消息无法被发送。
Broker向生产者返回确认发布成功(ACK)的状态，生产者继续发送下一条消息。

//单个
    public static  void confirmOne() throws  Exception{
        Channel channel = RabbitmqUtil.getChannel();
        String queueName  = UUID.randomUUID().toString();
        channel.queueDeclare(queueName,true,false,false,null);
        //开启发布确认
        channel.confirmSelect();
        //开始时间
        long begin = System.currentTimeMillis();
        for (int i = 0; i < QUEUE_TIME; i++) {
            String message=i+"";
            channel.basicPublish("",queueName, 
                   MessageProperties.PERSISTENT_TEXT_PLAIN,message.getBytes());
            //发送确认.单个发消息进行发布确认
            boolean b = channel.waitForConfirms();
            if(b==true){
                System.out.println("消息发送成功");
            }
        }

        long end=System.currentTimeMillis();
        System.out.println("发布"+QUEUE_TIME+"个单独消息，耗时"+(end-begin)+"ms");
    }

3.3批量发布确认

上面那种方式非常慢，与单个等待确认消息相比，先发布一批消息然后一起确认可以极大地提高吞吐量。

当然这种方式的缺点就是:当发生故障导致发布出现问题时，不知道是哪个消息出现问题了，我们必须将整个批处理保存在内存中，以记录重要的信息而后重新发布消息。当然这种方案仍然是同步的，也一样阻塞消息的发布。

//批量
    public static void confirmMany()throws  Exception{
        Channel channel = RabbitmqUtil.getChannel();
        String queueName  = UUID.randomUUID().toString();
        channel.queueDeclare(queueName,true,false,false,null);
        //开启发布确认
        channel.confirmSelect();
        //开始时间
        long begin = System.currentTimeMillis();
        //指定批量的大小
        int batchSize=100;
        for (int i = 0; i < QUEUE_TIME; i++) {
            String message=i+"";
            channel.basicPublish("",queueName, 
                  MessageProperties.PERSISTENT_TEXT_PLAIN,message.getBytes());

            //判断100，批量发送进行发布确认
            if(i%batchSize==0){
                System.out.println("消息发送成功");
                //发送发布确认
                 channel.waitForConfirms();
            }
        }

        long end=System.currentTimeMillis();
        System.out.println("发布"+QUEUE_TIME+"个消息批量，耗时"+(end-begin)+"ms");
    }

3.4异步发布确认

异步确认虽然编程逻辑比上两个要复杂，但是性价比最高，无论是可靠性还是效率都没得说，他是利用回调函数来达到消息可靠性传递的，这个中间件也是通过函数回调来保证是否投递成功。

首先在生产者发送消息之前，在生产者程序中设置一个确认发布监听addConfirmListener(ackCallback,nackCallback)，监听哪些消息的成功和失败。用于给Borker端调用，Broker将确认发布信息推送给生产者确认发布监听器，设置好监听器之后生产者就可以向Broker端推送消息了。

确认发布监听器与消息推送是两个独立的线程，所以推送消息和监听状态是可以并行的，也就是所谓的异步操作，生产者可以一直给Broker端推送消息，Broker端会将确认状态通过监听器回调给生产者，Broker端会给确认发布监听器传递两种确认发布的状态，确认成功(Confirm Ack)和确认失败(Confirm Nack)，生产者可以获取到成功或失败的消息，做其它处理，如将失败的消息重新发送。所以异步确认是性价比最好的。

生产者发送消息给Broker，可以一直发送
Broker在接收消息后，随时将发布确认的状态通过回调发送给生产者的监听器.
确认发布监听器将发送失败(Nack)的消息，进行处理重新发送。
确认发布监听器将发送成功(Ack)的消息，进行后续处理，比如进度日志等

//异步：原理--批量发送，只管发送，不管是否正确与否，消息实体broker会给生产者反应哪些消息出问题
    public static void confirmAsync()throws  Exception{
        //获取信道
        Channel channel = RabbitmqUtil.getChannel();
        //队列名
        String queueName = UUID.randomUUID().toString();
        //创建队列
        channel.queueDeclare(queueName,true,false,false,null);
        //开启发布确认
        channel.confirmSelect();

        //消息确认成功回调函数        var1消息的标识      var2是否批量确认
        ConfirmCallback ackCallback=(var1,var2)->{
            System.out.println("确认消息"+var1);
        };
        //消息确认失败回调函数
        ConfirmCallback nackCallback=(var1,var2)->{
            System.out.println("未确认消息"+var1);
        };
        //准备消息监听器。监听哪些消息成功和失败
        channel.addConfirmListener(ackCallback,nackCallback);

        long begin = System.currentTimeMillis();
        //批量发送消息
        for (int i = 0; i < QUEUE_TIME; i++) {
            String message=i+"";
            //发送消息
            channel.basicPublish("",queueName,MessageProperties.PERSISTENT_TEXT_PLAIN,message.getBytes());
        }

        long end = System.currentTimeMillis();
        System.out.println("发布"+QUEUE_TIME+"个消息异步，耗时"+(end-begin)+"ms");
    }

3.5如何处理异步未确认消息

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

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

单独发布消息

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

批量发布消息

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

异步处理

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

        //单个确认    发布100个消息，耗时32365ms
//        ConfirMessage.confirmOne();
        //批量确认   发布1000个消息批量，耗时438ms
//        ConfirMessage.confirmMany();
        //异步确认   发布1000个消息异步，耗时81ms
//        ConfirMessage.confirmAsync();