什么时候该使用MQ

2,289 阅读3分钟

MQ(消息队列)是什么

消息总线(Message Queue),简称MQ,是一种跨进程的通信机制,用于上下游传递消息。(这两个进程,一般不在同一台服务器上)

在架构中,MQ经常用做“上下游解耦”:

(1)消息发送方只依赖MQ,不关注消费方是谁;

(2)消息消费方也只依赖MQ,不关注发送方是谁;

什么时候不使用MQ

当调用方需要关心消息执行结果时,通常不使用MQ,而使用RPC调用

如上图所示,登陆调用主服务,不同的情况,业务会走不同的逻辑处理分支(登录成功,登录失败,执行错误等),即“处理结果强依赖”,此时应该使用RPC调用。

此时如果强行使用MQ呢?

强行使用MQ通讯,调用方不能直接告之用户登录成功或失败,需要等待另一个MQ通知回调。这样不但使得编码复杂,还会引入消息丢失的风险,中间多加入一层,多此一举。

那么文章的重点来了,那么我们什么时候使用呢?

什么时候使用MQ

列举三种该使用MQ的场景

一:顺序型依赖任务

首先,什么是任务依赖? 举个例子,项目中经常会有凌晨执行的一些数据统计的定时任务,这些任务之间有一定的依赖关系

(1)task3需要使用task2的输出作为输入;

(2)task2需要使用task1的输出作为输入;

则tast1, task2, task3之间就有任务依赖关系,也就是说必须先执行task1,再执行task2,最后执行task3。

那种这类需求,通常怎么实现呢?

常见的就是 crontab人工排执行时间表,也就是根据经验,判断每个任务的执行时间,给每个任务一个预定的时间去执行。

这样的话总任务的时间会很长,而且一旦对某个任务的时间判断不准确,将会得到错误的结果,并且任务的调换很不灵活。

那这个痛点我们要如何解决呢?

采用MQ解耦

如图。我们可以通过MQ来传递任务的结束和开始。

采用MQ的好处是什么呢?

当上游任务执行完,下游任务总会在第一时间被执行;

依赖的任务,只需要订阅相关消息即可;

并且有任务执行时间变化,下游任务都不需要调整执行时间。

二:不关心执行结果

上游需要关注执行结果时要用“RPC调用”,上游不关注执行结果时,使用MQ

不关心执行结果的采用MQ有什么好处呢?

(1)上游执行不需要关注下游;

(2)上下游逻辑+物理解耦,除了与MQ有物理连接,模块之间都不相互依赖;

(3)新增一个下游消息关注方,上游不需要修改任何代码;

三:上游关注执行结果,但执行时间很长

有时候上游需要关注执行结果,但执行结果时间很长。比如我们经常使用的微信支付,调用微信的接口,执行时间比较长, 但是调用方又非常关注执行结果。那这种需要如何处理呢?

一般采用回调+MQ来解决 (1)调用方直接调用微信接口;

(2)微信返回调用成功,但是此时并不代表返回成功;

(3)微信执行完成后,返回结果通知MQ;

(5)请求方收到结果通知;

什么时候不使用MQ

当调用方需要实时关注执行结果,通常采用RPC

总结

MQ是一个互联网架构中常见的解耦利器,希望这个小分享对大家有用