什么时候使用MQ
【典型场景一：数据驱动的任务依赖】 什么是任务依赖，举个栗子，互联网公司经常在凌晨进行一些数据统计任务，这些任务之间有一定的依赖关系，比如： 1）task3需要使用task2的输出作为输入 2）task2需要使用task1的输出作为输入 这样的话，tast1, task2, task3之间就有任务依赖关系，必须task1先执行，再task2执行，载task3执行。 优化方案是，采用MQ解耦： 1）task1准时开始，结束后发一个“task1 done”的消息 2）task2订阅“task1 done”的消息，收到消息后第一时间启动执行，结束后发一个“task2 done”的消息 3）task3同理 采用MQ的优点是： 1）不需要预留buffer，上游任务执行完，下游任务总会在第一时间被执行 2）依赖多个任务，被多个任务依赖都很好处理，只需要订阅相关消息即可 3）有任务执行时间变化，下游任务都不需要调整执行时间 需要特别说明的是，MQ只用来传递上游任务执行完成的消息，并不用于传递真正的输入输出数据。 【典型场景二：上游不关心执行结果】 上游需要关注执行结果时要用“调用”，上游不关注执行结果时，就可以使用MQ了。 举个栗子，58同城的很多下游需要关注“用户发布帖子”这个事件，比如招聘用户发布帖子后，招聘业务要奖励58豆，房产用户发布帖子后，房产业务要送2个置顶，二手用户发布帖子后，二手业务要修改用户统计数据。
优化方案是，采用MQ解耦： 1）帖子发布成功后，向MQ发一个消息 2）哪个下游关注“帖子发布成功”的消息，主动去MQ订阅 采用MQ的优点是： 1）上游执行时间短 2）上下游逻辑 物理解耦，除了与MQ有物理连接，模块之间都不相互依赖 3）新增一个下游消息关注方，上游不需要修改任何代码 典型场景三：上游关注执行结果，但执行时间很长 有时候上游需要关注执行结果，但执行结果时间很长（典型的是调用离线处理，或者跨公网调用），也经常使用回调网关 MQ来解耦。 举个栗子，微信支付，跨公网调用微信的接口，执行时间会比较长，但调用方又非常关注执行结果，此时一般怎么玩呢？
一般采用“回调网关 MQ”方案来解耦： 1）调用方直接跨公网调用微信接口 2）微信返回调用成功，此时并不代表返回成功 3）微信执行完成后，回调统一网关 4）网关将返回结果通知MQ 5）请求方收到结果通知 这里需要注意的是，不应该由回调网关来调用上游来通知结果，如果是这样的话，每次新增调用方，回调网关都需要修改代码，仍然会反向依赖，使用回调网关 MQ的方案，新增任何对微信支付的调用，都不需要修改代码啦。 五、总结 MQ是一个互联网架构中常见的解耦利器。
什么时候不使用MQ？ 上游实时关注执行结果 什么时候使用MQ？ 1）数据驱动的任务依赖 2）上游不关心多下游执行结果 3）异步返回执行时间长
参考
