RabbitMQ如何保证消息队列的可靠性传输
什么是消息队列的可靠性传输?
要想保证消息队列的可靠性传输,我们需要先弄明白 什么才是消息队列的可靠性传输?
我们先来分析一个简单的场景,只有一个生产者,一个队列,一个消费者。直观的了解消息队列的可靠性传输。
如图所示,生产者发送消息到消费者,中间的每一步都有可能发生错误,怎么保证在传输的过程中,即使出现了错误,程序仍然可以正确运行,这就是消息队列的可靠性传输。
分析及解决方案
先来分析一下图中的3个问题
问题1:如何确保生产者成功的将消息传输到队列?
- 在RabbitMQ中,我们可以使用RabbitMQ中提供的事务功能,传输消息之前,添加事务,如果消息传输的过程中出错了,我们就回滚事务,没有出现错误,我们就提交事务。但是,RabbitMQ中的事务机制是同步的,使用事务的话,太浪费性能。
- 一般来说,我们使用RabbitMQ中的 confirm 模式来保证消息一定正确传输到队列,或者传输出错我们再处理错误信息。关于 confirm 模式的使用,参考 RabbitMQ高级应用(一)消息的可靠性投递—消息确认机制(confirm模式)
问题2:如何确保消费者成功的消费了消息?
对于这个问题,我们可以使用 RabbitMQ中的 ACK 机制,就是手动确认消息。我们可以根据需求,自己设置接收成功或者接收失败之后的操作。
问题3:消费者消费成功,或者是消费失败,如何告知给生产者?
在这个简单的场景里,我们可以和问题2的解决方法一致,在手动签收消息之后做手动告诉生产者已经消费成功
实际开发场景分析
在实际的开发环境中,肯定不会只有一个生产者,一个消费者这么简单的问题,在实际开发中应该如何做呢?
假设现在有这么一个场景:
需要你实现一个 网上购物商城的订单服务,假如是某宝的剁手节,高达几个亿的并发量,程序运行中难免会出现各种各样的bug,如果在程序运行中,有那么几个订单,用户支付成功过后,因为你设计的程序问题,导致无法正常显示订单信息,显然不希望出现这种情况。所以我们一定要保证消息的准确性。
大致业务流程如下图所示:
上图只是大概显示了其中的业务流程,并没有做任何消息的可靠性保证。
我们需要考虑的问题:
- 如何确保队列服务成功的将消息传递给订单队列?
- 如果使用 confirm 机制,confirm机制提示发送失败了,需要做何处理?
- 怎么保证队列服务能成功的取出(消费)队列的消息?
- ACK机制如何进行后续处理?
方案一:消息入库,对消息状态进行标记
既然要把消息存入到数据库,就需要一个储存消息状态的表。
下面是添加上保证消息的可靠性机制的流程图
方案二:消息的延迟投递
这里使用记录日志来替代了订单服务,便于读者更好的理解,消息的延迟投递怎么保证消息传输的准确性
其实这个解决方案也很简单,这里使用了2个队列,一个用来记录日志,另一个用来校验信息的准确性