到底什么时候该使用MQ？

发布时间：2025-11-05 04:15:21 来源：云智核 作者：域名

一、到底缘起

一切脱离业务的什时使用架构设计与新技术引入都是耍流氓。

引入一个技术之前，候该首先应该解答的到底问题是，这个技术解决什么问题。什时使用

就像微服务分层架构之前，候该应该首先回答，到底为什么要引入微服务，什时使用微服务究竟解决什么问题(详见《互联网架构为什么要做微服务?候该》)。

最近分享了几篇MQ相关的到底文章：

不少网友询问，究竟什么时候使用MQ，什时使用MQ究竟适合什么场景，候该故有了此文。到底

二、什时使用MQ是候该干嘛的

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

在互联网架构中，MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。

使用了MQ之后，消息发送上游只需要依赖MQ，云服务器提供商逻辑上和物理上都不用依赖其他服务。

三、什么时候不使用消息总线

既然MQ是互联网分层架构中的解耦利器，那所有通讯都使用MQ岂不是很好?这是一个严重的误区，调用与被调用的关系，是无法被MQ取代的。

MQ的不足是：

举个栗子：用户登录场景，登录页面调用passport服务，passport服务的执行结果直接影响登录结果，此处的“登录页面”与“passport服务”就必须使用调用关系，而不能使用MQ通信。

无论如何，记住这个结论：调用方实时依赖执行结果的业务场景，云南idc服务商请使用调用，而不是MQ。

四、什么时候使用MQ

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

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

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

对于这类需求，常见的实现方式是，使用cron人工排执行时间表：

这种方法的坏处是：

无论如何，采用“cron排班表”的方法，各任务耦合，谁用过谁痛谁知道(采用此法的请评论留言)

优化方案是，采用MQ解耦：

采用MQ的优点是：

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

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

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

举个栗子，58同城的很多下游需要关注“用户发布帖子”这个事件，比如招聘用户发布帖子后，招聘业务要奖励58豆，房产用户发布帖子后，房产业务要送2个置顶，二手用户发布帖子后，二手业务要修改用户统计数据。

对于这类需求，常见的实现方式是，使用调用关系：

帖子发布服务执行完成之后，调用下游招聘业务、房产业务、二手业务，来完成消息的通知，但事实上，这个通知是否正常正确的执行，帖子发布服务根本不关注。

这种方法的坏处是：

优化方案是，采用MQ解耦：

采用MQ的优点是：

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

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

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

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

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

五、总结

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

什么时候不使用MQ?

什么时候使用MQ?

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

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

相关文章