RocketMQ深入浅出-01-MQ简介

写这个专题的初衷：一直都用MQ，但是没有系统的学习过，当和同事交流时，MQ的很多细节都说不上来，最近刷了两遍RocketMQ的视频，打算把笔记整理出来，和大家一起打卡，探究RocketMQ的真面目

MQ是什么

MQ是Message Queue（消息队列）的首字母缩写，基于“先进先出”的数据结构，是一种提供消息队列服务的中间件，也称为消息中间件，是一套提供了消息生产、存储、消费全过程API的软件系统。消息即数据。一般消息的体量不会很大。一般用来解决应用解耦，异步消息，流量削峰等问题，实现高性能，高可用，可伸缩和最终一致性架构。

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。

MQ常见协议

一般情况下MQ的实现是要遵循一些常规性协议的。

常见的协议如下：

JMS 

JMS，Java Messaging Service（Java消息服务）。是Java平台上有关MOM（Message Oriented Middleware，面向消息的中间件 PO/OO/AO）的技术规范，它便于消息系统中的Java应用程序进行消息交换，并且通过提供标准的产生、发送、接收消息的接口，简化企业应用的开发。ActiveMQ是该协议的典型实现。

STOMP 

STOMP，Streaming Text Orientated Message Protocol（面向流文本的消息协议），是一种MOM设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。ActiveMQ是该协议的典型实现，RabbitMQ通过插件可以支持该协议。 

AMQP

AMQP，Advanced Message Queuing Protocol（高级消息队列协议），一个提供统一消息服务的应用层标准，是应用层协议的一个开放标准，是一种MOM设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。RabbitMQ是该协议的典型实现。

MQTT 

MQTT，Message Queuing Telemetry Transport（消息队列遥测传输），是IBM开发的一个即时通讯协议，是一种二进制协议，主要用于服务器和低功耗IoT（物联网）设备间的通信。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和制动器的通信协议。RabbitMQ通过插件可以支持该协议。

本节主要讲述了什么是MQ、MQ的应用场景、优缺点、常见MQ对比以及MQ常用协议介绍。下一节将带你探究RocketMQ的发展历程及安装部署搭建！

本文转载自公众号BiggerBoy