RabbitMQ消息中间件技术精讲9 高级篇二
高并发场景下，消息的延迟投递做二次确认进行回调检查来保障生产者消息投递成功的可靠性
在上一篇文章中，我们介绍了BAT大厂中一种方式保障生成者消息投递可靠性。思考：在上一篇中可靠性投递，在高并发的场景下是否合适？
其实在上一篇文章中，我们实际上对数据库操作了两次：业务数据入库和消息信息入库。这中对数据库多次操作的，如果在高并发场景下会出现问题的。所以我们可以使用二种情况：消息的延迟投递，做二次确认，回调检查。
本文主要内容：
消息的延迟投递做二次确认，回调检查。
延迟投递流程图：
流程说明：
Upstream Service:上游服务
DownStream Service:下游服务
Callback service:回调服务
执行流程：
Step1：
业务信息入库(BIZ DB)之后，向MQ发送一个消息：first Send。这个消息时通知下游服务进行下游业务处理的；
Setp2:
First Send消息发送后，同时发送一个Second Send Delay Check消息。这个消息是用来延时check验证的。如延迟5分钟(具体延迟多少时间，根据实际业务)；
Setp3:
下游服务有一个用于接收上有服务发送消息的消费者:Listener Consume。当消费者接收到生产者发送的消息后进行业务处理。处理完成后，执行第四步操作；
Setp4:
当消费者消费后，自己业务处理完成之后，会发送一个确认的消息(Send Confirm)给队列。
Step5:
下游服务生产一个确认消息后，在回调服务(Callback Serivce)中会有一个消费者(Listener Confirm)消费这个确认消息后，将消息信息入库或更新消息状态。
五分钟后，延迟校验消息开始生效，进行校验，进行第六步
Setp6:
当延迟校验在Callback Service服务中进行查询消息库，发现没有或者是状态没有进行预期的更新后，延迟校验会会通过主键或者其他唯一标识通过RPC方式发起一个RPC ReSend Command请求到上游服务，询问此条消息下游未正常处理。请求上游服务再次发送消息操作。
此种操作相对于第一种操作的优点：减少了一次同步操作数据库的操作。这样在高并发的情况下就能提高效率。
好了，两种保障生产者投递消息可靠性已经讲完了。在下节课中，我们将讲解下一个知识点：幂等性。下节预告：
1：幂等性是什么
2：在海量订单产生的业务高峰期，如何避免消息的重复消费问题？
3：业界主流的幂等性操作都有哪些？
欢迎关注凯哥公众号：凯哥Java(kaigejava)
凯哥个人博客：www.kaigejava.com
