MQ什么时候用？

深藏阁楼爱情的钟 2024-04-19 09:10 120阅读 0赞

# MQ是干嘛的 #

**消息总线**（Message Queue），称为MQ，是一种跨进程的通信机制，用于上下游传递消息。  
![在这里插入图片描述][20190916150932484.png]  
在互联网架构中，MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了MQ之后，消息发送上游只需要依赖MQ，逻辑上和物理上都不用依赖其他服务。

## 什么时候不适用消息总线 ##

MQ的不足：

1.  系统更复杂，多了一个MQ组件。
2.  消息传递路径更长，延时会增加。
3.  消息可靠性和重复性互为矛盾，消息不丢不重难以同时保证。
4.  上游无法知道下游的执行结果，这一点很致命。

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

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

## 什么时候使用MQ ##

场景1：任务依赖

任务三需要使用任务二的输出作为输入  
任务二需要使用任务一的输出作为输入  
对于这类需求，常见的实现方式是，使用cron人工排执行时间表：  
1）task1，0:00执行，经验执行时间为50分钟2）task2，1:00执行（为task1预留10分钟buffer），经验执行时间也是50分钟  
3）task3，2:00执行（为task2预留10分钟buffer）

**这种方法的坏处是**：

1.  如果有一个任务执行时间超过了预留buffer的时间，将会得到错误的结果，因为后置任务不清楚前置任务是否执行成功，此时要手动重跑任务，还有可能要调整排班表
2.  总任务的执行时间很长，总是要预留很多buffer，如果前置任务提前完成，后置任务不会提前开始
3.  如果一个任务被多个任务依赖，这个任务将会称为关键路径，排班表很难体现依赖关系，容易出错
4.  如果有一个任务的执行时间要调整，将会有多个任务的执行时间要调整

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

1.  任务一开始，结束后发送一个“task1 done”的消息给任务二。
2.  任务二收到task1 done的消息，第一时间开始执行，结束后发送task2 done消息给任务三。
3.  task3同理。

**采用MQ的优点**：  
（1）不需要预留buffer，上游执行完下游会第一时间被执行。  
（2）依赖多个任务，被多个任务依赖都很好处理，只需要订阅相关详细即可。  
（3）有任务执行时间变化，下游任务都不需要调整执行时间。  
需要特别说明的是，MQ只是用来传递上游任务执行完成的消息，并不用于传递真正的输入输出数据。

**场景2：上游不关心执行结果**

上游需要关注执行结果要用“调用”，上游不关注执行结果时，就可以使用MQ了。  
举个例子：58同城的很多下游需要关注“用户发布帖子”这个事件，比如招聘用户发布帖子后，招聘业务要奖励58豆，房产用户发布帖子后，房产业务要送2个置顶，二手用户发布帖子后，二手业务要修改用户统计数据。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JheHhkd3lw_size_16_color_FFFFFF_t_70]  
对于这类需求，常用的实现方式就是使用调用  
但是这种方法的坏处是：  
（1）帖子发布流程的执行时间增加了。  
（2）下游服务宕机，可能导致帖子发布服务受影响，上下游逻辑+物理依赖严重。  
（3）每当增加一个需要知道“帖子发布成功”信息的下游，修改代码的是帖子发布服务，这一点最恶心的，数据架构设计中典型的依赖倒转。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JheHhkd3lw_size_16_color_FFFFFF_t_70 1]  
**优化方案是，采用MQ解耦：**  
（1）帖子发布成功后，主动向MQ发送消息。  
（2）那个下游关注“帖子发布成功”，主要向MQ订阅。  
**采用MQ的优点是：**  
（1）上游执行时间短。  
（2）上下游逻辑+物理解耦，除了与MQ有物理连接，模块之间都不相互依赖。  
（3）新增以下下有消息关注方，上游不需要修改任何代码。

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

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JheHhkd3lw_size_16_color_FFFFFF_t_70 2]  
一般采用“回调网关+MQ”方案来解耦：  
（1）调用方直接跨公网调用微信接口。  
（2）微信返回调用成功，次是并不代表返回成功。  
（3）微信执行完成后，回调统一网关。  
（4）网关将返回结果通知MQ。  
（5）请求方收到结果通知。

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

## 总结 ##

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

**什么时候不使用MQ？**  
上游实时关注执行的结果。

**什么时候使用MQ？**  
（1）任务依赖  
（2）上游不关心多下游的执行结果  
（3）异步返回执行时间长

[20190916150932484.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/5b84471ba9df42139213207a85cb4775.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JheHhkd3lw_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/e68786048c034725867520f50cdfc526.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JheHhkd3lw_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/400fd701d5914b72b25c233aba82fcee.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JheHhkd3lw_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/2b441c4c3cc54e94a59d114ef42c3ba2.png