RocketMQ深入浅出-01-MQ简介

MQ介绍

MQ是什么

MQ是Message Queue（消息队列）的首字母缩写，是基础数据结构中“先进先出”的一种数据结构。一般用来解决应用解耦，异步消息，流量削峰等问题，实现高性能，高可用，可伸缩和最终一致性架构。

MQ中主要有三个角色，queue队列、producer生产者，consumer消费者。
队列（queue）：一种“先进先出“的数据结构
消息队列（message queue）：使用队列这种数据结构存储消息的中间件
消息生产者（producer）：向消息队列发送消息
消息消费者（producer）：从消息队列拿消息，做相应处理

为什么要用MQ？

要说为什么用MQ，不得不说一下MQ的应用场景，其应用场景主要包含以下3个方面

• 应用解耦

系统的耦合性越高，容错性就越低。以电商应用为例，用户创建订单后，如果订单系统耦合调用库存系统、物流系统、支付系统的接口，那么任何一个子系统出故障或者因为升级等原因暂时不可用，都会造成下单操作异常，影响用户使用体验。

如下图，使用消息队列解耦合，系统的耦合性就会降低。比如物流系统发生故障，需要几分钟才能修复，在这段时间内，物流系统要处理的数据被缓存到消息队列中，用户的下单操作能正常完成。当物流系统恢复后，补充处理存储在消息队列中的订单消息即可，订单系统感知不到物流系统发生过故障。

• 流量削峰

一般情况下，我们的系统都是直接操作数据库的，如下图所示，用户请求A系统，A系统对数据库进行CRUD。

对于一般的系统，请求量不大，没有高并发场景的话，这么做没有问题，但是应用系统如果遇到系统请求流量的瞬间猛增，有可能会将系统压垮，特别是关系型数据库，QPS撑死也就两三千，如果瞬时请求每秒5千，那么数据库撑不住就会挂掉，导致整个系统不可用。有了消息队列可以将大量请求缓存起来，后端系统以一种平稳的速度消费其中的消息，这样就达到了流量削峰，因为平时很长一段时间里服务器资源都在闲置（请求数很低，服务器资源没有充分利用起来），这样将瞬时大量请求，先集中收集起来，然后分散到很长一段时间处理，可以大大提高系统的稳定性，起到保护系统的作用，提高用户体验，让用户能正常使用系统。

一般情况，为了保证系统的稳定性，如果系统负载超过阈值，就会阻止用户请求，这会影响用户体验，而如果使用消息队列将请求缓存起来，等待系统处理完毕后通知用户下单完毕，这样总比不能下单体验要好。
出于经济考量目的：
假如业务系统正常时段的QPS是1000，流量最高峰值是10000，如果仅仅为了应对流量高峰而配置高性能的服务器显然不划算，性价比不高，所以这时就可以使用消息队列对峰值流量削峰。

• 数据分发

我们先看下图，描述了这样一个关系：A系统产生数据后，因为某些业务需求，需要B、C、D系统做某些处理。传统的做法是A系统在产生数据后调用B、C、D系统提供的接口。
假如在后期版本迭代时，B系统的负责人说了，因为需求变化你A系统不需要再调我了。于是A系统的老哥就改代码，把调用B系统的逻辑注释掉，然后测试打包上线。过了一段时间，C系统也说了，我这边需求也变化了，只有在某些情况下你再调我的接口，啪，扔过来一堆逻辑判断条件。A系统是改还不是不该？当然得改！假如这时候又新增了一个E系统也需要A调用呢？A系统更崩溃了！一个功能反反复复来回改动，要知道凡是改动都可能引起bug！此时此刻，A系统的负责人心想：这么样的架构设计真不合理，升级一下架构！

怎么升级呢？引入消息队列就可以。通过消息队列可以让数据在多个系统之间进行流通。数据的产生方不需要关心谁来使用数据，只需要将数据发送到消息队列，数据使用方直接在消息队列中直接获取数据即可。

升级后的架构如下图。在系统之间引入MQ，A系统产生数据后，把期发到MQ中就不用管了。其他系统只需要从MQ中取消息即可，至于你取不取，取完怎么用都和我A系统没关系了。一下子清爽了！

MQ的优点和缺点

基于MQ的应用场景总结一下优缺点。
优点：解耦、削峰、数据分发
缺点包含以下几点：

• 系统可用性降低
  系统引入的外部依赖越多，系统稳定性越差。一旦MQ宕机，就会对业务造成影响。
  此时要考虑的问题是如何保证MQ的高可用？
• 系统复杂度提高
  MQ的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过MQ进行异步调用。
  此时系统需要额外的考虑很多问题，比如：如何保证消息没有被重复消费？怎么处理消息丢失情况？怎么保证消息传递的顺序性？
• 一致性问题
  A系统处理完业务，通过MQ给B、C、D三个系统发消息数据，如果B系统、C系统处理成功，D系统处理失败。
  此时需要考虑如何保证消息数据处理的一致性？

各种MQ产品的比较

常见的MQ产品包括Kafka、ActiveMQ、RabbitMQ、RocketMQ。