一、生产者消息丢失原因
由于消息中间件有着削峰、解耦等好处,已经在业界得到了广泛的应用。
常见的应用场景为:
这里的订单系统为生产者,结算系统为消费者。
但是一般而言,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的高可用,比如跨机房集群等