本文为joshua317原创文章,转载请注明：转载自joshua317博客 https://www.joshua317.com/article/132
现给结论：解耦,异步,削峰
（1）解耦
A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃......A 系统跟其它各种乱七八糟的系统严重耦合，A 系统 产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。如果使用 MQ，A 系统产生一 条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。 就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦。
（2）异步
A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库 要 3ms，BCD 三个系统分别写库要 400ms、350ms、300ms。最终请求总延时是 3 + 100 + 250 + 300 = 1053ms，整个耗时超过1s，用户感觉搞个什么东西，慢得要命。用户通过浏览器发起请求。如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应 给用户，总时长是 3 + 5 = 8ms。
（3）削峰
减少高峰时期对服务器压力。
当然，MQ有很多优点，但也不乏缺点优，主要缺点有以下几个
（1）系统可用性降低，系统引入的外部依赖越多，越容易挂掉。万一 MQ 挂了，MQ 一挂，整套系统崩溃，你不就完了？
（2）系统复杂度提高，硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的 顺序性？问题一大堆。
（3）一致性问题 A 系统处理完了直接返回成功了，会以为此次请求就成功了；但是问题是，要是 BCD 三个系统里面，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。
至于mq的缺点也是能够克服的，大家可以动脑思考下，如何解决呢？
本文为joshua317原创文章,转载请注明：转载自joshua317博客 https://www.joshua317.com/article/132