初探MQ

什么是MQ

关于MQ的概念，想必都不陌生，MQ是 Message Queue（消息队列） 的缩写，所以他首先是一个队列，有先进先出的特性，其次是一个存放消息的队列。常用在分布式系统中进行通信。

为什么用MQ

每引入一个中间件，都会提高系统的开发和维护成本，当然为了保证其高可用购买服务器，也会提升成本。那么我们为什么要用MQ呢，他到底有什么好处呢，网上很多总结，大致有三点：应用解耦、异步提速、削峰填谷。

应用解耦

假设12306系统是这样的，我们买票成功后，需要做以下几件事：调用库存系统扣减车票库存，调用短信系统给用户发送短信，调用邮件系统给用户发邮件，调用第三方客户端通知买票成功。那么如果这几个服务一直能正常服务，产品经理不在有新的需求变更，那也可称得上现世安稳，岁月静好。可是万一有一天出现这么两种情况可怎么办呢？

产品经理提需求，好多人关注了我们12306微信客户端，我们需要买票成功后在通知微信小程序。那么我们又需要修改订单系统的代码。一次还好，如果隔一段时间发生一件这样的事，那谁能忍受？
某一天，短信系统挂了，然后客户成功买到一张票，然后呢是短信也没收到，邮件也没收到，库存也没扣，这还得了。你短信系统坏了，我邮件系统好好的，凭什么影响我，让客户收不到邮件，这就不合理。

所以呢，还是各个系统之间的耦合太高了，我们应该解耦。不是有人说互联网的任何问题都可以通过一个中间件来解决吗，那么我们看MQ如何帮我们解决这件棘手的事情。

那么我们发现其实短信系统、邮件系统等都只依赖订单系统产生的一条数据那就是订单，因此我们在订单系统产生数据后，将订单这条数据发送给MQ，就返回成功，然后让短信、邮件等系统都订阅MQ，一旦发现MQ有消息，他们主动拉取消息，然后解析，进行业务处理。这样一来，就算你短信系统挂了，丝毫不会影响其他系统，而且如果后来想加一个新的系统，你也不用改订单系统的代码了，你只要订阅我们的MQ提供的消息就行了。

异步提速

还以上面12306为例，假设我们不用MQ，那么我们的代码必然耦合在一起，下单成功后，依次要通过RPC远程调用这几个系统，然后同步等到他们的响应才能返回给用户是否成功的结果。假设每个系统耗时200ms，那么就得花费600ms。

但是其实有时候我们发现，下单是个核心业务，可能压力本来就大，客户也着急知道下单是否成功，但是短信邮件等通知，可能大多数人根本不急或者压根不关心，那么我们为什么要让这些细枝末节的业务影响核心业务的效率呢，是不是有点舍本逐末。所以这个逻辑我们可以设计成异步的。我们可以当下单成功后，只需要将订单消息发给MQ，然后立即将结果返回通知客户。这才是正确的打开姿势。这样一来，我订单系统只需要告诉你MQ，我下单成功了，其他模块收到消息后，该发短信的发短信，发邮件的发邮件。因为本来MQ的性能就很好，所以这个效率一下就提升了。

削峰填谷

还是用12306为例，假设平时可能买票的人不多，所以订单系统的QPS也不是很高，每秒也就处理1000个请求，但是一到节假日、春运期间可能抢票的人就非常多，并发量远远大于平时，这个时候，订单系统明显扛不住了。怎么办呢，当然我们可以设计弹性伸缩的集群，进行机器扩容，保证高可用。但是我们依然可以采用MQ来解决这个问题。

MQ的吞吐能力还是还强大的，所以我们可以设计高可用的MQ，让所有的请求都打到MQ，缓存起来。这样一来高峰期的流量和数据都将积压在MQ中，流量高峰就被削弱了（削峰），然后我们的订单系统就避免了高并发的请求，它可以慢慢的从MQ中拉取自己能力范围内的消息就行处理。这样一来，高峰期积压的消息也终将被消费完，可以叫做填谷。

总结

综上所述，MQ有他的优势，主要体现在三个方面

应用解耦：提高系统容错性和可维护性
异步提速：提升响应速度，优化用户体验
削峰填谷：高并发的时候，可以有效保证系统的稳定性

当然他也有弊端

复杂度提高，我们需要解决消息丢失、积压、幂等等各种情况
一旦MQ宕机，对业务有影响

常见MQ性能对比

这里从网上找的一张性能对比图，可以大概对比一下几大主流MQ的优缺点。ActiveMQ因为吞吐量低，也没有什么突出的优势，用的人也少了。RabbitMQ主要特点是消息延迟低，并发能力强，而且安全可靠，所以并发量不是很大的金融行业据说用的多，互联网公司可能用的少，因为他的开发语言是Erlang，可能懂得人不多，出问题不好定位。而RocketMQ是阿里开源的MQ，并发高，功能多，用的好像挺多。Kafka主要用在大数据领域。这些话呢，也主要是网上看的，并没有实际调研过，有确切的数据，不过理论上是可信的。

01-初探MQ-MQ的三大使用场景：应用解耦、异步提速、削峰填谷相关推荐

高可用服务 AHAS 在消息队列 MQ 削峰填谷场景下的应用...
在消息队列中,当消费者去消费消息的时候,无论是通过 pull 的方式还是 push 的方式,都可能会出现大批量的消息突刺.如果此时要处理所有消息,很可能会导致系统负载过高,影响稳定性.但其实可能后面几 ...
高并发系统设计：消息队列的三大作用：削峰填谷、异步处理、模块解耦
削去秒杀场景下的峰值写流量而在秒杀场景下,高并发的写请求并不是持续的,也不是经常发生的,而只有在秒杀活动开始后的几秒或者十几秒时间内才会存在.为了应对这十几秒的瞬间写高峰,将秒杀请求暂存在消息队列中 ...
面向削峰填谷的电动汽车多目标优化调度策略代码主要实现了考虑电动汽车参与削峰填谷的场景下，电动汽车充放电策略的优化，是一个多目标优化
MATLAB代码:面向削峰填谷的电动汽车多目标优化调度策略关键词:电动汽车削峰填谷多目标充放电优化仿真平台:MATLAB YALMIP+CPLEX 主要内容:代码主要实现了考虑电动汽车参与削 ...
为什么使用mq？具体的使用场景是什么？
mq的作用很简单,削峰填谷.以电商交易下单的场景来说,正向交易的过程可能涉及到创建订单.扣减库存.扣减活动预算.扣减积分等等.每个接口的耗时如果是100ms,那么理论上整个下单的链路就需要耗费400m ...
消息中间件系列(六)：什么是流量削峰？如何解决秒杀业务的削峰场景
流量削峰的由来主要是还是来自于互联网的业务场景,例如,马上即将开始的春节火车票抢购,大量的用户需要同一时间去抢购:以及大家熟知的阿里双11秒杀, 短时间上亿的用户涌入,瞬间流量巨大(高并发),比如: ...
MQ消息队列的使用场景
一.消息队列概述消息队列中间件是分布式系统中重要的组件,主要解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构.目前使用较多的消息队列有ActiveMQ,Rabbit ...
rpa机器人平台_RPA在财务领域的三大应用场景解析
RPA正在为企业财务带来新的数字化转型浪潮.伴随普华永道.毕马威.安永.德勤对财务机器人"不遗余力"地推广,RPA风潮早已在财务.金融领域刮起. RPA机器人流程自动化 RPA的核 ...
直播回顾 | 数据驱动实践的三大运营场景讲解
近日,神策数据进行了一场题为<数据驱动实践的三大运营场景讲解>的专题直播,直播中结合各行业的数据驱动企业的优质实践经验,针对三大运营场景进行了逐一详解,获得了阵阵好评,不少学员索要视频回放 ...
5G技术构成：透过eMBB、mMTC、uRLLC三大应用场景从通信技术根源出发
术语: eMBB(移动宽带增强).mMTC(大规模物联网,更多的称为海量机器类通信 [1-2] ).uRLLC(超高可靠超低时延通信) eMBB Enhanced Mobile Bro ...
5G 的三大应用场景——ITU-R原文
每次写 5G 的材料时都会提及 5G 的三大应用场景.虽然这是一个众人皆知的常识,但是如果不引用一下的话有些不严谨.苦于一直没找到 ITU 的原文,之前引用的都是移动通信教材那本书.今天狠下心来花时间 ...

01-初探MQ-MQ的三大使用场景：应用解耦、异步提速、削峰填谷