MQ应用探秘：通信利器的常见场景与优缺点解析

系列文章目录

---

前言

一、分布式消息队列应用场景分析

系统解耦

假设你有个系统A，这个系统A会产出一个核心数据，现在下游有系统B和系统C需要这个数据。

那简单，系统A就是直接调用系统B和系统C的接口发送数据给他们就好了。
整个过程，如下图所示。

但是现在要是来了系统D、系统E、系统F、系统G，等等，十来个其他系统慢慢的都需要这份核心数据呢？如下图所示。

如果某个系统产出一份核心数据，可能下游无数的其他系统都需要这份数据来实现各种业务逻辑。

此时如果你要是采取上面那种模式来设计系统架构，那么绝对你负责系统A的同学要被烦死了。

先是来一个人找他要求发送数据给一个新的系统H，系统A的同学要修改代码然后在那个代码里加入调用新系统H的流程。

一会那个系统B是个陈旧老系统要下线了，告诉系统A的同学：别给我发送数据了，接着系统A再次修改代码不再给这个系统B。

然后如果要是某个下游系统突然宕机了呢？系统A的调用代码里是不是会抛异常？那系统A的同学会收到报警说异常了，结果他还要去care是下游哪个系统宕机了。

所以在实际的系统架构设计中，如果全部采取这种系统耦合的方式，在某些场景下绝对是不合适的，系统耦合度太严重。

因此在上述系统架构中，就可以采用MQ中间件来实现系统解耦。

系统A就把自己的一份核心数据发到MQ里，下游哪个系统感兴趣自己去消费即可，不需要了就取消数据的消费，如下图所示。

异步调用

假设你有一个系统调用链路，是系统A调用系统B，一般耗时20ms；系统B调用系统C，一般耗时200ms；系统C调用系统D，一般耗时2s，如下图所示。

举个例子，你平时点个外卖，咔嚓一下子下订单然后付款了，此时账户扣款、创建订单、通知商家给你准备菜品。

接着，是不是需要找个骑手给你送餐？那这个找骑手的过程，是需要一套复杂算法来实现调度的，比较耗时。

但是其实稍微晚个几十秒完成骑手的调度都是ok的，因为实际并不需要在你支付的一瞬间立马给你找好骑手，也没那个必要。

那么我们是不是就可以把找骑手给你送餐的这个步骤从链路中抽离出去，做成异步化的，哪怕延迟个几十秒，但是只要在一定时间范围内给你找到一个骑手去送餐就可以了。

这样是不是就可以让你下订单点外卖的速度变得超快？支付成功之后，直接创建好订单、账户扣款、通知商家立马给你准备做菜就ok了，这个过程可能就几百毫秒。

然后后台异步化的耗费可能几十秒通过调度算法给你找到一个骑手去送餐，但是这个步骤不影响我们快速下订单。

当然我们不是说那些大家熟悉的外卖平台的技术架构就一定是这么实现的，只不过是用一个生活中常见的例子给大家举例说明而已。

所以上面的链路也是同理，如果业务流程支持异步化的话，是不是就可以考虑把系统C对系统D的调用抽离出去做成异步化的，不要放在链路中同步依次调用。

这样，实现思路就是系统A -> 系统B -> 系统C，直接就耗费220ms后直接成功了。

然后系统C就是发送个消息到MQ中间件里，由系统D消费到消息之后慢慢的异步来执行这个耗时2s的业务处理。通过这种方式直接将核心链路的执行性能提升了10倍。

整个过程，如下图所示。

流量削峰

假设你有一个系统，平时正常的时候每秒可能就几百个请求，系统部署在8核16G的机器的上，正常处理都是ok的，每秒几百请求是可以轻松抗住的。

但是如下图所示，在高峰期一下子来了每秒钟几千请求，瞬时出现了流量高峰，此时你的选择是要搞10台机器，抗住每秒几千请求的瞬时高峰吗？

那如果瞬时高峰每天就那么半个小时，接着直接就降低为了每秒就几百请求，如果你线上部署了很多台机器，那么每台机器就处理每秒几十个请求就可以了，这不是有点浪费机器资源吗？

大部分时候，每秒几百请求，一台机器就足够了，但是为了抗那每天瞬时的高峰，硬是部署了10台机器，每天就那半个小时有用，别的时候都是浪费资源的。

但是如果你就部署一台机器，那会导致瞬时高峰时，一下子压垮你的系统，因为绝对无法抗住每秒几千的请求高峰。

此时我们就可以用MQ中间件来进行流量削峰。所有机器前面部署一层MQ，平时每秒几百请求大家都可以轻松接收消息。

一旦到了瞬时高峰期，一下涌入每秒几千的请求，就可以积压在MQ里面，然后那一台机器慢慢的处理和消费。

等高峰期过了，再消费一段时间，MQ里积压的数据就消费完毕了。

这个就是很典型的一个MQ的用法，用有限的机器资源承载高并发请求，如果业务场景允许异步削峰，高峰期积压一些请求在MQ里，然后高峰期过了，后台系统在一定时间内消费完毕不再积压的话，那就很适合用这种技术方案。

凡事有利必有弊，消息中间件虽然诸多优点，但是存在许多缺点，主要存在以下几点：

系统可用性降低： 系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。

系统复杂性提高： 硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已

一致性问题： A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。

二、分布式消息队列应用需要思考的问题

• 消息发布端的可靠性投递
  • 如果业务和钱相关，这个消息就一定不能丢失
  • 需要做到消息生产端的100%投递，就一定要有消息的补偿机制
• 消费端的幂等
  • 生产端做到可靠性投递，就可能会重复投递消息
  • 消费端消费了两次或多次同一个数据，就可能会导致数据不一致
  • 随意无论消费端重复消费多少次，都应该只能有一个结果
• MQ本身需要考虑的内容
  • HA：高可用
  • 低延迟：虽然MQ是用于弱依赖，也不能因为MQ导致延迟过大
  • 可靠性：数据是否完整
  • 堆积能力：这个MQ是否能够扛下你的业务量级
  • 扩展性：是否能够支持横向扩展