当前位置: 首页 > news >正文

深入浅出 RabbitMQ-消息可靠性投递

大家好,我是工藤学编程 🦉一个正在努力学习的小博主,期待你的关注
实战代码系列最新文章😉C++实现图书管理系统(Qt C++ GUI界面版)
SpringBoot实战系列🐷【SpringBoot实战系列】SpringBoot3.X 整合 MinIO 存储原生方案
分库分表分库分表之实战-sharding-JDBC分库分表执行流程原理剖析
消息队列深入浅出 RabbitMQ - SpringBoot2.X整合RabbitMQ实战

前情摘要:

1、深入浅出 RabbitMQ-核心概念介绍与容器化部署
2、深入浅出 RabbitMQ-简单队列实战
3、深入浅出 RabbitMQ-工作队列实战(轮训策略VS公平策略)
4、深入浅出 RabbitMQ-交换机详解与发布订阅模型实战
4、深入浅出 RabbitMQ-路由模式详解
5、深入浅出 RabbitMQ - 主题模式(Topic)
6、深入浅出 RabbitMQ - SpringBoot2.X整合RabbitMQ实战

本文章目录

  • 深入浅出 RabbitMQ-消息可靠性投递
    • 一、什么是消息可靠性投递?
    • 二、RabbitMQ消息投递路径与关键控制点
    • 三、可靠性投递核心机制
      • 1. 生产者到交换机:ConfirmCallback机制
        • 配置方式(SpringBoot环境):
        • 实战代码:
        • 异常模拟:
      • 2. 交换机到队列:ReturnCallback机制
        • 配置方式:
        • 实战代码:
    • 四、注意事项:可靠性与性能的权衡
    • 总结

深入浅出 RabbitMQ-消息可靠性投递

在分布式系统中,消息队列作为解耦服务、削峰填谷的核心组件,其消息传递的可靠性直接影响业务稳定性。想象一下,电商订单支付后因消息丢失导致物流系统未触发发货,这样的问题足以让用户流失。今天我们就深入探讨RabbitMQ如何实现消息的可靠性投递,从底层原理到实战代码一网打尽。

一、什么是消息可靠性投递?

消息可靠性投递指的是确保消息从生产者发送到消费者的全链路过程中不丢失,具体包含三层含义:

  1. 消息百分百到达消息队列(避免网络波动导致的丢失)
  2. 消息队列节点成功接收并持久化消息(防止节点宕机丢失)
  3. 生产者能明确感知消息发送状态,对失败消息有完善的补偿机制(重试、存储等)

二、RabbitMQ消息投递路径与关键控制点

RabbitMQ的消息投递路径是:生产者 → 交换机(Exchange)→ 队列(Queue)→ 消费者

在这条路径上,有两个最容易发生消息丢失的节点,也是我们需要重点控制的环节:

  • 生产者到交换机的投递过程
  • 交换机到队列的路由过程

“为什么消息进入队列后,相对不容易发生丢失?” 或者 “为什么队列到消费者的环节相对不容易丢失消息?”,可以从 RabbitMQ 的设计机制来解释:

  1. 队列本身的存储特性保障了消息的稳定性
    消息进入队列后,RabbitMQ 会将消息存储在磁盘(持久化配置下)或内存中,队列的设计天然具备抗丢失能力:
    持久化机制:如果队列声明时设置了durable=true(持久化队列),且消息发送时设置了deliveryMode=2(持久化消息),那么消息会被写入磁盘。即使 RabbitMQ 节点宕机重启,队列和消息也能从磁盘恢复,避免了内存数据丢失的风险。
    镜像队列:在集群环境中,队列可以配置为 “镜像队列”(Mirror Queue),消息会同步到多个节点的副本中。即使主节点故障,从节点也能接管,避免单节点故障导致的消息丢失。
  2. 队列到消费者的投递机制有明确的确认机制
    消息从队列投递到消费者时,RabbitMQ 通过消费者确认机制(Ack) 确保消息被正确处理,避免丢失:
    消费者默认需要显式发送ack(确认)信号:当消费者处理完消息后,必须手动发送确认(channel.basicAck()),队列才会删除该消息。
    若消费者未确认且断开连接(如崩溃),队列会将消息重新投递:这种 “未确认则重发” 的机制,确保了消费者未处理成功的消息不会被丢弃。
    可以设置autoAck=false(关闭自动确认):避免消费者还没处理完消息就自动确认,导致处理失败后消息丢失。
  3. 队列到生产者的 “回退” 是异常场景,且有明确触发条件
    只有在交换机到队列路由失败时(如路由键不匹配、队列不存在),且开启了mandatory=true,消息才会通过ReturnCallback回退给生产者。这种场景下:
    回退的是 “未成功路由到队列的消息”,本质是 “交换机到队列” 环节的失败处理,而非正常的 “队列到生产者” 流程。
    此时消息并未进入队列,所以不存在 “队列存储后再丢失” 的问题 —— 因为消息根本没被队列接收,直接被回退了。

三、可靠性投递核心机制

1. 生产者到交换机:ConfirmCallback机制

当生产者发送消息后,RabbitMQ的Broker节点收到消息会返回一个ACK确认信号。通过ConfirmCallback回调,生产者可以明确知道消息是否成功到达交换机,这是可靠性投递的核心机制。

配置方式(SpringBoot环境):
# 新版配置(推荐)
spring.rabbitmq.publisher-confirm-type: correlated  # 消息到达交换机后触发回调
# 旧版配置(已过时)
# spring.rabbitmq.publisher-confirms: true
实战代码:
@Autowired
private RabbitTemplate rabbitTemplate;@Test
void testConfirmCallback() {// 设置确认回调rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> {System.out.println("=====ConfirmCallback触发====");System.out.println("消息是否到达交换机:" + (ack ? "成功" : "失败"));System.out.println("失败原因:" + cause);// 业务处理:失败时可记录日志、执行重试或存入本地消息表if (!ack) {log.error("消息发送失败,准备重试: {}", correlationData.getId());// retryLogic(correlationData);}});// 发送消息CorrelationData correlationData = new CorrelationData(UUID.randomUUID().toString()); // 消息唯一标识rabbitTemplate.convertAndSend("order.exchange",  // 交换机名称"order.new",       // 路由键"新订单创建:ID=1001",  // 消息内容correlationData);
}
异常模拟:

若故意修改交换机名称为不存在的"invalid.exchange",回调会收到ack=false,并返回"channel error; protocol method: #method<channel.close>(reply-code=404, reply-text=NOT_FOUND - no exchange ‘invalid.exchange’ in vhost ‘/’, class-id=60, method-id=40)"的错误原因。

2. 交换机到队列:ReturnCallback机制

消息成功到达交换机后,若因路由键错误、队列不存在等原因导致无法路由到队列,默认情况下消息会被直接丢弃。ReturnCallback机制可以捕获这类路由失败的消息,让生产者有机会处理。

配置方式:
spring.rabbitmq.publisher-returns: true  # 开启返回回调
spring.rabbitmq.template.mandatory: true  # 强制要求路由失败时返回消息
实战代码:
@Test
void testReturnCallback() {// 设置返回回调rabbitTemplate.setReturnsCallback(returnedMessage -> {System.out.println("=====ReturnCallback触发====");System.out.println("状态码:" + returnedMessage.getReplyCode());System.out.println("路由失败原因:" + returnedMessage.getReplyText());System.out.println("交换机:" + returnedMessage.getExchange());System.out.println("路由键:" + returnedMessage.getRoutingKey());System.out.println("消息内容:" + new String(returnedMessage.getMessage().getBody()));// 业务处理:可记录失败消息,人工介入或重新投递});// 发送消息(故意使用错误路由键)rabbitTemplate.convertAndSend("order.exchange","invalid.key",  // 不存在的路由键"新订单创建:ID=1002");
}

四、注意事项:可靠性与性能的权衡

开启Confirm和Return机制后,每一条消息都会增加一次网络交互(Broker返回确认),这会导致:

  • RabbitMQ整体吞吐量下降约30%-50%
  • 生产者处理链路变长,增加响应时间

因此,非核心业务消息不建议开启(如日志收集、非关键通知)。对于核心业务(订单、支付),可结合本地消息表实现最终一致性:

  1. 发送消息前先存入数据库(状态:待发送)
  2. 收到ConfirmCallback成功确认后更新状态(状态:已发送)
  3. 定期扫描未确认消息,执行重试

总结

RabbitMQ的消息可靠性投递通过两大回调机制实现:

  • ConfirmCallback:确保消息到达交换机
  • ReturnCallback:确保消息从交换机路由到队列

在实际应用中,需根据业务重要性权衡可靠性与性能,核心场景建议结合本地消息表做补偿,非核心场景可适当放宽策略。

掌握这些机制,就能在分布式系统中构建起可靠的消息传递链路,为业务稳定性保驾护航。

觉得有用请点赞收藏!
如果有相关问题,欢迎评论区留言讨论~

http://www.xdnf.cn/news/1430371.html

相关文章:

  • 学习日记-SpringMVC-day48-9.2
  • WPF应用程序资源和样式的使用示例
  • 洗衣店小程序的设计与实现
  • 深度学习篇---DenseNet网络结构
  • gitlab中回退代码,CI / CD 联系运维同事处理
  • VR森林经营模拟体验带动旅游经济发展
  • Time-MOE 音频序列分类任务
  • 【C++框架#2】gflags 和 gtest 安装使用
  • Redis 的跳跃表:像商场多层导航系统一样的有序结构
  • 疯狂星期四文案网第58天运营日记
  • 大模型微调数据准备全指南:清洗、标注与高质量训练集构造实战
  • 科研界“外挂”诞生了:科学多模态模型Intern-S1-mini开源
  • 我的项目我做主:Focalboard+cpolar让团队协作摆脱平台依赖
  • 大数据毕业设计选题推荐-基于大数据的电脑硬件数据分析系统-Hadoop-Spark-数据可视化-BigData
  • 临时邮箱地址获取服务器邮件工作流程与实现
  • playwright+python 实现图片对比
  • 【代码里的英雄传】Dubbo 的一生:一位分布式勇士的传奇旅程
  • 依托深兰科技AI技术生态,深兰教育携手沪上高校企业启动就业科创营
  • 高性能接口实现方案
  • 【微服务】-Gson反序列化泛型类型踩坑指南:如何正确处理Result<T>类型
  • MTK Linux DRM分析(三十)- MTK mtk_dsi.c(Part.2)
  • AI零售创业公司:零眸智能
  • PHP操作LibreOffice将替换变量后的word文件转换为PDF文件
  • ffmpeg 安装
  • C#基础(⑤ProcessStartInfo类和Process类)
  • Centos10虚拟机安装Zabbix
  • 面试tips--MySQLRedis--Redis 有序集合用跳表不用B+树 MySQL用B+树作为存储引擎不用跳表:原因如下
  • 卫朋:基于IPD思维的产品规划逻辑
  • Android Binder 驱动 - Media 服务启动流程
  • 三格电子CAN总线通信原理及在消防领域中的应用