539、RabbitMQ详细入门教程系列 -【100%消息投递消费(一)】 2022.08.31

一、前言概述

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

在这里插入图片描述

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

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

二、事务TX

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

2.1 相关操作

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

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

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定位到消息进行操作

四、参考链接

[01] RabbitMQ详细入门教程系列 -【100%消息投递消费(一)】

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值