您好,登录后才能下订单哦!
这篇文章给大家分享的是有关RabbitMQ如何实现消息的可靠性投递的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。
一般的消息中间件(MQ)只能保证消息不丢,但是不能保证重复发送等问题。
比如在使用Rabbitmq过程中,如何保证消息都能正确的投递被消费,这个是要考虑的问题。
那么可靠性投递所面临的问题有哪些?
1. 如果发送的消息重复怎么办。
2. 如果消息发送过程中丢了怎么办。
3. 如何保证MQ节点成功收到消息。
针对这个问题RabbitMQ提供了以下几个机制来解决:
生产者确认
持久化
手动Ack
下图是Rabbitmq一个完整的消息可靠投递的一个方案。
我们来分析下。
Step1:Producer所发送的数据是我们的业务数据,比如订单信息。Producer在发送消息之前给我们的订单信息写入我们的本地数据库(BIZ DB)中,BIZ DB是我们的业务数据库,接着将要发送到消息存储到消息记录数据库中(MSG DB),这个MSG DB就是存储所有发送给Rabbitmq的消息记录用的,写入消息记录表中该记录字段status(状态)会有几个值,比如0表示消息发送中,1表示发送成功,2表示消息发送失败,。
Step2:应用程序要消息发送给Rabbitmq的Broker,这个发送的消息属于confirm模式,发送后需要Rabbitmq确认。
Step3:Rabbitmq Broker收到消息后会给Producer一个应答来确认信息,说我已经收到消息了。
Step4:紧跟上一步,Producer一直在监听(Listener)Broker所确认的信息,在收到消息之后,根据收到消息的结果再去更新MSG DB中的消息发送状态,将记录status字段更新为1。
Step 5:但是在消息确认这个过程中可能由于网络闪断、MQ Broker端异常等原因导致 回送消息失败或者异常。这个时候就需要发送方(生产者)对消息进行可靠性投递了,保障消息不丢失,100%的投递成功!(有一种极限情况是闪断,Broker返回的成功确认消息,但是生产端由于网络闪断没收到,这个时候重新投递可能会造成消息重复,需要消费端去做幂等处理)所以我们需要有一个定时任务,(比如每5分钟拉取一下处于中间状态的消息,当然这个消息可以设置一个超时时间,比如超过1分钟 Status = 0 ,也就说明了1分钟这个时间窗口内,我们的消息没有被确认,那么会被定时任务拉取出来)。
Step 6:接下来我们把中间状态的消息进行重新投递 retry send,继续发送消息到MQ ,当然也可能有多种原因导致发送失败
Step 7:我们可以采用设置最大努力尝试次数,比如投递了3次,还是失败,那么我们可以将最终状态设置为Status = 2 ,最后 交由人工解决处理此类问题(或者把消息转储到失败表中)。
感谢各位的阅读!关于“RabbitMQ如何实现消息的可靠性投递”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,让大家可以学到更多知识,如果觉得文章不错,可以把它分享出去让更多的人看到吧!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。