欢迎关注文章系列 ，关注我
《提升能力，涨薪可待》-为什么要使用MQ消息中间件
场景一：系统解耦
假设你有个系统A，这个系统A会产出一个核心数据，现在下游有系统B和系统C需要使用这个数据。
首先想到最简单，系统A就是直接调用系统B和系统C的接口发送数据给他们就好了
但是现在要是来了系统D、系统E、系统F、系统G，等等，十来个其他系统都需要这份核心数据呢？
这是可能会出现开发人员最头疼的、尴尬的问题？
先是来一个人找他要求发送数据给一个新的系统H，系统A的同学要修改代码然后在那个代码里加入调用新系统H的流程。
那我们现在该怎么做呢？系统的耦合性那么高，这真是牵一发而动全身，小需求需要大改动，何必呢？2
现在我们主角要来了，可以使用MQ消息中间件，让我们系统之间耦合度降低。
现在我们只需要将系统A自己的一份核心数据发送到MQ中间件中，下游哪个系统感兴趣自己去消费即可。
这样能达到一次编译不必改，谁爱谁去改，反正我不改。
总结：通过 MQ 消息中间件的使用，重构系统之间的耦合，让系统具备高度的可扩展性。
场景二：异步调用
假设你有一个系统调用链路，是系统A调用系统B，一般耗时20ms；系统B调用系统C，一般耗时200ms；系统C调用系统D，一般耗时2s
用户一个请求过来巨慢无比，就像走过长长的套路一样
因为走完一个链路，需要耗费：
20ms + 200ms + 2000ms（2s） = 2220ms，
也就是2秒多的时间。但是实际上，链路中的系统A调用系统B，系统B调用系统C，这两个步骤起来也就220ms。
这时候主角大佬又慢慢的过来了，这都搞不定，不是很简单吗？
实现思路就是系统A -> 系统B -> 系统C，直接就耗费220ms后直接成功了。
然后系统C就是发送个消息到MQ中间件里，由系统D消费到消息之后慢慢的异步来执行这个耗时2s的业务处理。通过这种方式直接将核心链路的执行性能提升了10倍。
总结：
1）对用户来说，比同步时更加快捷，用户体验非常好。（让用户以为自己抢到了，欺骗ing ）
2）对系统访问压力来说，异步因为没有真正执行，不会造成某时刻对系统的访问压力剧增，而是放入队列，慢慢去消费！
场景三：流量削峰
假设你有一个系统，平时正常的时候每秒可能就几百个请求，系统部署在8核16G的机器的上，正常处理都是OK的，每秒几百请求是可以轻松抗住的。比如秒杀活动
在秒杀活动在高峰期一下子来了每秒钟几千、万请求，弹指一挥间出现了流量高峰。
如果时候出现机器宕机，公司损失可是大大的，这是你是不是该准备好被老板痛骂，甚至可能要say goodbye
可能想到的解决的方式，线上部署了很多台机器，一多制胜的方法：
但是，假设除了秒杀活动达到瞬时高峰，其它时间基本为每秒就几百请求，如果你线上部署了很多台机器，就是为了这次秒杀活动，这有点浪费机器资源。
所以这时，MQ大哥又出现了，不怕，这不是还有我吗？
在所有机器前面部署一层MQ，平时每秒几百请求大家都可以轻松接收消息。一旦到了瞬时高峰期，一下涌入每秒几千的请求，就可以积压在MQ里面，然后那一台机器慢慢的处理和消费。
总结：削峰从本质上来说就是更多地延缓用户请求，以及层层过滤用户的访问需求，遵从“最后落地到数据库的请求数要尽量少”的原则。
最后MQ还有其他场景，通知、数据分发等等，能体现使用MQ中间件的好处。
也欢迎关注微信公众号【Ccww笔记】，原创技术文章第一时间推出
