使用RabbitMQ如何保证消息不丢失 ?

简介: RabbitMQ通过发布者确认、回执机制、消息持久化及消费者确认等方案,确保消息从发送到接收的每个环节都能有效防止丢失。即便如此,特殊情况下仍可能丢失,如系统故障等。为此,可设计消息状态表,记录消息ID、内容、交换机、路由键、发送时间和签收状态等,结合定时任务检查并重发未签收消息,以进一步提升消息传输的可靠性。

消息从发送,到消费者接收,会经理多个过程 , 其中的每一步都可能导致消息丢失
针对这些问题,RabbitMQ分别给出了解决方案:
● 消息发送到交换机丢失 : 发布者确认机制publisher-confirm消息发送到交换机失败会向生产者返回ACK , 生产者通过回调接收发送结果 , 如果发送失败, 重新发送, 或者记录日志人工介入
● 消息从交换机路由到队列丢失 : 发布者回执机制publisher-return消息从交换机路由到队列失败会向生产者返回失败原因 , 生产者通过回调接收回调结果 , 如果发送失败, 重新发送, 或者记录日志人工介入
● 消息保存到队列中丢失 : MQ持久化(交换机持久化, 队列持久化 , 消息持久化)
● 消费者消费消息丢失 : 消费者确认机制 , 消费者失败重试机制
通过RabbitMQ本身所提供的机制基本上已经可以保证消息不丢失 , 但是因为一些特殊的原因还是会发送消息丢失问题 , 例如 : 回调丢失 , 系统宕机, 磁盘损坏等 , 这种概率很小 , 但是如果想规避这些问题 , 进一步提高消息发送的成功率, 也可以通过程序自己进行控制
设计一个消息状态表 , 主要包含 : 消息id , 消息内容 , 交换机 , 消息路由key , 发送时间, 签收状态等字段 , 发送方业务执行完毕之后 , 向消息状态表保存一条消息记录, 消息状态为未签收 , 之后再向MQ发送消息 , 消费方接收消息消费完毕之后 , 向发送方发送一条签收消息 , 发送方接收到签收消息之后 , 修改消息状态表中的消息状态为已签收 ! 之后通过定时任务扫描消息状态表中这些未签收的消息 , 重新发送消息, 直到成功为止 , 对于已经完成消费的消息定时清理即可 !

相关实践学习
快速体验阿里云云消息队列RocketMQ版
本实验将带您快速体验使用云消息队列RocketMQ版Serverless系列实例进行获取接入点、创建Topic、创建订阅组、收发消息、查看消息轨迹和仪表盘。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
目录
相关文章
|
存储 Python
海明距离(Hamming Distance)
海明距离(Hamming Distance)是用来衡量两个二进制数之间差异程度的指标,它表示两个二进制数之间最多有多少个比特的差异。海明距离可以用于衡量数据传输或存储中的错误率,以及检测噪声干扰。 海明距离的计算方法是:对于两个 n 位二进制数,将它们进行逐位比较,如果对应位上的数字不同,则计算距离时增加 1。然后将所有位上的距离加在一起,得到海明距离。
3595 1
|
消息中间件 NoSQL Java
【RabbitMQ】RabbitMQ如何做到保证消息100%不丢失?
【RabbitMQ】RabbitMQ如何做到保证消息100%不丢失?
1236 0
|
5月前
|
关系型数据库 MySQL 数据库
锁机制避坑指南:3个让DBA头皮发麻的“锁升级”陷阱
本文揭示MySQL InnoDB中行锁意外升级为表锁的三种常见场景:1)WHERE条件无索引导致全表扫描锁;2)外键约束自动加锁子表;3)RR隔离级别下间隙锁扩大范围。针对每种情况提出解决方案:建立索引、评估外键必要性、降低隔离级别等。通过EXPLAIN分析、监控死锁日志可快速定位问题,避免并发性能骤降。掌握这些锁机制特性,能有效提升数据库并发处理能力。
|
7月前
|
存储 人工智能 物联网
大模型微调内存优化全攻略:无需昂贵显卡,打造你的AI助手
本文深入解析大模型微调为何“烧显存”,从原理(模型参数、优化器状态、激活值三大显存杀手)到实战:推荐QLoRA等高效方法,结合梯度累积、序列截断、混合精度与DeepSpeed优化,并介绍LLaMA-Factory Online等低门槛平台,助开发者用消费级显卡轻松微调专属模型。(239字)
684 22
大模型微调内存优化全攻略:无需昂贵显卡,打造你的AI助手
|
5月前
|
传感器 人工智能 运维
AgentRAG三大核心能力:意图识别+任务规划+经验库问答
AgentRAG创新性融合ReAct Agent、知识库与Skill,以意图识别、任务规划、经验库问答三大能力,破解传统RAG答非所问、难解复杂问题、无法复用企业经验等痛点,让AI真正懂业务、可落地、易部署。(238字)
530 0
|
10月前
|
SQL 关系型数据库 MySQL
MySQL慢sql的排查与优化
本文详解MySQL慢查询排查与优化,涵盖EXPLAIN执行计划分析、索引失效场景及10大优化方案,如避免全表扫描、合理使用索引、分页与排序优化等,助力提升数据库性能。
MySQL慢sql的排查与优化
|
SQL JSON 关系型数据库
EXPLAIN详解:MySQL查询优化必备工具
本文深入解析了MySQL中的EXPLAIN命令,帮助开发者识别和优化慢查询。通过分析执行计划,读者可以了解查询的性能瓶颈,并采取相应措施提升数据库效率。
|
机器学习/深度学习 人工智能 搜索推荐
《解锁增强型上下文学习,打造你的专属智能助手》
个性化人工智能助手通过增强型上下文学习技术,大幅提升性能与交互体验。该技术让助手不仅理解当前指令,还能结合历史对话和用户偏好,实现精准意图理解、连贯对话体验及个性化内容推荐。在智能办公、教育辅导和生活助手等领域,它助力高效工作、定制化学习和便捷生活。然而,数据隐私与算法优化仍是挑战,未来技术完善将使人机交互更智能高效。
1269 3
|
存储 消息中间件 运维
使用Redis的优势以及会引发的问题
Redis作为一种高性能、功能丰富的内存数据结构存储系统,在缓存、消息队列和实时数据处理等场景中具有显著优势。然而,使用Redis也可能引发内存消耗大、数据一致性问题和运维复杂性等挑战。了解Redis的优缺点,合理设计和优化系统架构,可以充分发挥Redis的优势,同时避免潜在的问题。希望本文能够为您在实际应用中提供有价值的参考和指导。
471 1
|
SQL 关系型数据库 MySQL
小索引大力量,记一次explain的性能优化经历
本文介绍了在MySQL生产环境中使用EXPLAIN工具进行性能优化的过程。通过分析慢查询日志,识别出性能瓶颈,并利用EXPLAIN命令解析SQL执行计划,找出全表扫描、未使用索引等问题。文章还详细描述了如何配置慢查询日志、解读EXPLAIN输出的关键字段(如type、key、rows等),并提供了优化建议,如避免左右模糊查询、减少多表联查等。最终验证优化效果,确保系统性能提升。此外,强调了项目初期建立索引的重要性,以应对未来数据量增长带来的挑战。
736 0