RbbitMQ(五) -- 100%消息投递消费

最新推荐文章于 2023-04-10 09:02:17 发布

周仕林

最新推荐文章于 2023-04-10 09:02:17 发布

阅读量341

点赞数

分类专栏： MQ 文章标签： RabbitMQ

本文链接：https://blog.csdn.net/weixin_43495590/article/details/102521723

版权

MQ 专栏收录该内容

5 篇文章 2 订阅

订阅专栏

一：前言概述

生产者生产消息到消费者消息消费，中间需要生产者将消息发送到交换器，再由交换器路由到队列存储，然后消费者进行消息消费。在没有任何设置情况下，中间可能存在以下几种情况导致消息丢失：
在这里插入图片描述

消费者将消息发送到交换器因为RabbitMQ内部原因丢失消息
交换器将消息路由到队列，因为队列不存在等因素导致消息丢失
队列中存储的消息在消费者未消费时RabbitMQ服务宕机导致消息丢失
消费者消费消息时消费者宕机未处理完消息导致消息丢失

针对上述情况，本文将根据每个节点讲述如何操作确保消息投递的可靠性，同时在保障可靠性的情况下可能会引发系列如消息重复等问题，也是本文将会涉及到的重点

二：事务TX

理解数据库的事务就是将多次操作原子化，统一提交回滚实现数据一致性。RabbitMQ事务可能与之前数据库等事务有一定差别，当然也是支持消息的提交与回滚操作。事务是解决生产者发送消息到交换器消息丢失问题的方案之一

2.1 相关操作

RabbitMQ中的事务实现有如下两个个主要步骤：
在这里插入图片描述

将通信的信道设置为事务模式
事务提交/事务回滚

2.2 代码示例

        // 将信道设置为事务模式
        channel.txSelect();
        // 发送消息
        try {
            channel.basicPublish(bindingKey, bindingKey, false, false, null, messgae.getBytes("UTF-8"));
            // 提交事务
            channel.txCommit();
        }catch (Exception e){
            // 异常回滚事务,发生异常的时候可以尝试重发或者记录等操作
            channel.txRollback();
        }

2.3 总结

事务机制的确认需要等待上一条消息发送完毕反馈之后才能进行第二条消息发送，这样的操作将会对于使用RabbitMQ而言感觉就是暴殄天物。如果是想要发送多条消息只能循环操作，但是注意如果没有将channel信道设置为事务模式不能进行事务操作，不然会抛出异常。最后一点就是信道设置为事务模式只需要操作一次即可

三：确认Confirm

事务机制对于RabbitMQ性能消耗是灾难性的，针对生产者到交换器消息丢失处理提出了全新的轻量级处理方式。发送发确认机制confirm，该操作编码上会有很多地方都在讲什么等待确认、批量确认、异步确认。一切为了生产，所以本文将只会介绍生产用的异步确认方式

3.1 相关操作

RabbitMQ的生产发送确认实现由以下三个部分构成：

将信道channel设置为确认模式
增加确认监听Listener
处理监听结果

3.2 代码示例

每个通道发送到RabbitMQ的Broker中都会有唯一的编码
生产端最好使用有序队列存储发送的消息，方便确认后的删除
创建Channel通道时可以指定唯一编码，标识该通道

        // 设置confirm消息发送确认机制
        channel.confirmSelect();
        // 增加确认机制监听器
        channel.addConfirmListener(new ConfirmListener() {
            /**
             * 成功确认
             * deliveryTag 表示消息的唯一标识
             * multiple 本次确认是否为批量操作
             */
            @Override
            public void handleAck (long deliveryTag, boolean multiple) throws IOException {
                // 删除有序集合中的消息
                if (! multiple){
                    // 根据坐标删除消息
                }else {
                    // 批量删除消息
                }
            }
    
            /**
             * 失败确认
             * deliveryTag 表示消息的唯一标识
             * multiple 本次确认是否为批量操作
             */
            @Override
            public void handleNack (long deliveryTag, boolean multiple) throws IOException {
                // 可以根据deliveryTag做重试操作等
            }
        });

3.3 注意事项

在这里插入图片描述

共存：事务与确认机制不能共存，不然会异常
查验：通过RabbitMQ可视化监控界面可看到Channels栏Mod属性T表示事务，C表示监听确认
有序：因为RabbitMQ生成的序列deliveryTag是由小到大自动递增的，所以最好存储消息的时候考虑到顺序性，更方便通过deliveryTag定位到消息进行操作

四：Mandatory

交换器不存储消息，所有消息都要路由到队列存储。如果中间过程消息丢失，对于生产者而言不设置的情况下是无法知晓的错误。Mandatory实现与Confirm实现类似，通过增加监控监听Listener实现。前面文章消息与队列进阶详细描述过这个参数监听

4.1 相关操作

当消息到达交换器，但是没有匹配队列路由存储时。若通过Mandatory实现监听处理则需要如下几个处理过程：

发送消息basicPublish()时将设置mandatory参数为true
为信道channel增加MandatoryListener监听

4.2 代码示例

首先可以看到因为bindingKey与routingKey不一致，消息不能路由到队列
然后可以看到发送消息时将mandatory参数设置为true表示增加mandatory监听
最后可以看到在信道上增加了ReturnLisrtener监听，取得未路由消息相关参数信息

4.3 参数详解

ReturnListener中仅仅包含唯一方法handleReturn()，该方法中含有系列参数，参数含义如下表所示：

参数	描述
replyCode	表示本次返回消息原因编码，如312消息未路由
replyText	表示本次返回消息原因描述
exchange	监听器接收到返回消息的交换器
routingKey	本次消息发送的路由键
properties	本次监听到返回消息的属性设置
body	监听到返回消息的消息体