究竟什么时候该使用MQ？

发布时间：2025-11-05 02:40:10 来源：创站工坊 作者：IT科技

任何脱离业务的究竟组件引入都是耍流氓。引入一个组件，什时使用最先该解答的候该问题是，此组件解决什么问题。究竟

MQ，什时使用互联网技术体系中一个常见组件，候该究竟什么时候不使用MQ，究竟究竟什么时候使用MQ，什时使用MQ究竟适合什么场景，候该是究竟今天要分享的内容。

MQ是什时使用什么?

消息总线(Message Queue)，后文称MQ，候该是究竟一种跨进程的通信机制，用于上下游传递消息。什时使用

画外音：这两个进程，候该一般不在同一台服务器上。

在互联网架构中，MQ经常用做“上下游解耦”：

画外音：发送方与消费方，逻辑上和物理上都不依赖彼此。

什么时候不使用MQ?

当调用方需要关心消息执行结果时，通常不使用MQ，云服务器而使用RPC调用。

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

画外音：绝大部分情况，应该使用RPC。

此时如果强行使用MQ呢?

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

究竟什么时候使用MQ呢?

下面四类典型场景，应该使用MQ。

典型场景一：数据驱动的任务依赖

(1) 什么是任务依赖?

举个栗子，互联网公司经常在凌晨进行一些数据统计任务，这些任务之间有一定的依赖关系，例如：

这样的话，站群服务器tast1, task2, task3之间就有任务依赖关系，必须task1先执行，再task2执行，载task3执行。

(2) 对于这类需求，通常怎么实现呢?

常见的玩法是，crontab人工排执行时间表。

如上图，手动设定如下：

crontab手动排表有什么坏处呢?

无论如何，采用“crontab排班表”的方法，各任务严重耦合，谁用过谁痛谁知道。

画外音：用过的，痛过的，请留言。

(3) 应该如何优化呢?

采用MQ解耦。

如上图，任务之间通过MQ来传递“开始”与“结束”的通知：

(4) 采用MQ有什么好处呢?

需要特别说明的是，MQ只用来传递上游任务执行完成的消息，并不用于传递真正的输入输出数据。

典型场景二：上游不关心执行结果 

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

举个栗子，58同城的很多下游需要关注“用户发布帖子”这个事件，比如：

(1) 对于这类需求，可以采用什么方式实现呢?

比较无脑的，可以使用RPC调用来实现：帖子发布服务执行完成之后，调用下游招聘业务、房产业务、二手业务，来完成消息的通知。

但事实上，这个通知是否正常正确的执行，帖子发布服务根本不关注。

(2) 通过RPC来传递不需要知道处理结果的通知，有什么坏处呢?

画外音：这一点是最恶心的，属于架构设计中典型的反向依赖。

(3) 如何来进行优化呢?

采用MQ解耦，代替RPC。

如上图所示：

(4) 如此一来，有什么好处呢?

典型场景三：上游关注执行结果，但执行时间很长

有时候上游需要关注执行结果，但执行结果时间很长(典型的是调用离线处理，或者跨公网调用)，也经常使用回调网关+MQ来解耦。

举个栗子，微信支付，跨公网调用微信的接口，执行时间会比较长，但调用方又非常关注执行结果，此时一般怎么玩呢?

一般采用“回调网关+MQ”方案来解耦：

这里需要注意的是，不应该由回调网关来RPC通知上游来通知结果，如果是这样的话，每次新增调用方，回调网关都需要修改代码，仍然会反向依赖，使用回调网关+MQ的方案，新增任何对微信支付的调用，都不需要修改代码。

结尾总结

MQ是一个互联网架构中常见的解耦利器。

什么时候不使用MQ?

上游实时关注执行结果，通常采用RPC。

什么时候使用MQ?

知其然，知其所以然，希望大家有收获。

【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文

相关文章