发消息不入库可以吗?不依赖数据库_高并发情况下 队列的100%可靠消费

不依赖数据库_高并发情况下 队列的100%可靠消费

发送消息前要不要先入DB呢?

传统的方式一般都要先DB后发送消息,但是如果系统并发量超高时，如果减少一次DB,性能将提高很多。

但是如果不落库，那么怎么能够保证消息的100%可靠呢？

传统的发消息架构

​

高并发情况下的消息队列100%架构

这个架构也是我们线上正在使用的架构。

采用中间服务异步补偿的方式来保证消息的可靠，100%消费。

详细流程如下

1. 等到业务数据事务提交之后，上游端 发送一条消息 ，并且同时发送一条校验的延迟消息(具体时间根据自己的业务定)。

2. try 住步骤一中发消息的方法

   1. 这是为了防止消息服务器网络抖动引起的发送消息失败
   2. 然后定时任务重新发送
   3. （如果您的消息服务是高可用架构)也可以不落库直接记录日志,少了很多麻烦，因为发生这种情况是很少的几乎不会发生。

3. 下游端监听 正常消息队列消费其中的消息

4. 下游端消费成功后发送一条消费成功的消息放到消息成功处理队列中。

5. CallBack服务 监听消息成功处理队列 ，得到某条消息成功处理，此时将这条成功处理的消息进行落库。

6. CallBack服务 同时也会去监听延迟校验消息队列 此时步骤1中的延迟消息到达 CallBack服务监听到

7. CallBack服务 将延迟消息中的能够表示消息的唯一性id 去数据库中查，如果能够查到 说明该消息已经成功被处理了。

8. CallBack服务 消费延迟校验消息时发现这个消息并没有被成功消费，此时 通知上游段重新发送。

rabbitmq也可以使用这种方式 忽略confirm不用在confirm中处理，而是使用中间补偿服务也起到了解耦的目的。

架构实现源码地址