如何实现mq生产者消息的可靠性投递


一、生产者消息丢失原因

  由于消息中间件有着削峰、解耦等好处,已经在业界得到了广泛的应用。
  常见的应用场景为:
在这里插入图片描述
  这里的订单系统为生产者,结算系统为消费者。
  但是一般而言,MQ中间件为了提高系统的吞吐量,会把消息保存在内存中。如果不作其他处理,MQ服务器一旦意外宕机,生产者投递的消息将全部丢失。
  因此,我们需要达到两个目标:
  (1)消息持久化
  (2)消息投递成功的确认机制


二、解决办法

1、MQ持久化 + 确认回调机制

  许多MQ都支持将内存中的消息持久化到磁盘中。比如RabbitMQ,其在发消息的时候有个durable参数可以设置。设置为true,就会持久化。
  而是否持久化成功,是由MQ来进行回调通知的。比如RabbitMQ就有一个confirm机制

(1)消息生产者把消息发送给MQ,如果接收成功,MQ会返回一个ack消息给生产者
(2)如果消息接收不成功,MQ会返回一个nack消息给生产者

在这里插入图片描述

  通过开启mq的持久化,以及使用其确认回调机制,在一定程度上已经解决了消息丢失的问题。

1.1、缺陷

  然而,为了吞吐量,MQ不可能每条消息都直接持久化到磁盘中,而是要先积累到一定量之后才会持久化。在这过程中如果MQ服务器宕机,这部分数据依旧会丢失。
  因此,也就有了下面的这个方案。

2、消息提前持久化 + 定时任务补偿机制 + 接口幂等

流程图如下:
在这里插入图片描述

流程说明如下:

(1)订单服务生产者在投递消息之前,先把消息持久化到Redis或DB中,建议Redis,高性能。消息的状态为发送中。
(2)confirm机制监听消息是否发送成功?如ack成功消息,删除Redis中此消息。
(3)如果nack不成功的消息,这个可以根据自身的业务选择是否重发此消息。也可以删除此消息,由自己的业务决定。
(4)这边加了个定时任务,来拉取隔一定时间内,消息状态还是为发送中的,这个状态就表明,生产者没有收到ack成功消息。
(5)定时任务会作补偿性的投递消息。这个时候如果MQ回调ack成功接收了,再把Redis中此消息删除。
(6)定时任务那边我们还可以加上一个补偿的次数,如果大于3次,还是没有收到ack消息 ,那就直接把消息的状态设置为【失败】,由人工去排查到底是为什么

2.1、注意点

(1)这里的补偿机制,生产者可能会发送多次同样的消息。因此,消息者必须保证消费时的幂等性。
   消费方的幂等性在后续的其他文章中,再进行详细描述。
(2)本方案也需要保障MQ的高可用,比如跨机房集群等


参考文章

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值