Spring Cloud Alibaba - 消息队列（一）（RocketMQ）（介绍（这篇不重要，下一篇很重要，主要是下一篇坑太多了））

回溯

通过之前的博文，除了Nacos的配置管理还没有讲解以外，其实已经可以初步的支持微服务的开发了，那么从这篇开始，就对开发过程中有可能（经常）用到的组件进行讲解吧，这篇讲解的是消息队列。

ps（这篇看看就好，下一篇很很很重要） ps：主要是下一篇的一些坑是天坑，博主差点没爬出来！！

MQ介绍

MQ（Message Queue）是一种跨进程的通信机制，用于传递消息。通俗点说，就是一个先进先出的数据结构。

正常的交互中，无论是通过 RPC 还是 RESTFUL ，消费者都是直接调用生产者，虽然这种方式是没有问题的。

但是在某些业务中，是需要解耦的，所以我们需要在中间添加一个中间件，就是MQ。

好看一点的图~

MQ的应用场景

异步解耦

最常见的一个场景是用户注册后，需要发送注册邮件和短信通知，以告知用户注册成功。传统的做法如下：

此架构下注册、邮件、短信三个任务全部完成后，才返回注册结果到客户端，用户才能使用账号登录。但是对于用户来说，注册功能实际只需要注册系统存储用户的账户信息后，该用户便可以登录，而后续的注册短信和邮件不是即时需要关注的步骤。

如果不解藕，用户接到通知需要等待 访问注册系统 访问邮件系统 访问短信系统 都成功后才能成功，这样消耗的时间太长了，用户交互不太友好。

所以实际当数据写入注册系统后，注册系统就可以把其他的操作放入对应的消息队列 MQ 中然后马上返回用户结果，由消息队列 MQ 异步地进行这些操作。架构图如下：

这样就无须等待 邮件系统 和 短信系统 的交互了。

异步解耦是消息队列 MQ 的主要特点，主要目的是减少请求响应时间和解耦。主要的使用场景就是将比较耗时而且不需要即时（同步）返回结果的操作作为消息放入消息队列。同时，由于使用了消息队列MQ，只要保证消息格式不变，消息的发送方和接收方并不需要彼此联系，也不需要受对方的影响，即解耦合。

流量削峰

流量削峰也是消息队列 MQ 的常用场景，一般在秒杀或团队抢购(高并发)活动中使用广泛。

在秒杀或团队抢购活动中，由于用户请求量较大，导致流量暴增，秒杀的应用在处理如此大量的访问流量后，下游的通知系统无法承载海量的调用量，甚至会导致系统崩溃等问题而发生漏通知的情况。为解决这些问题，可在应用和下游通知系统之间加入消息队列 MQ。

常用的MQ有哪些

• ZeroMQ
  号称最快的消息队列系统，尤其针对大吞吐量的需求场景。扩展性好，开发比较灵活，采用C语言实现，实际上只是一个socket库的重新封装，如果做为消息队列使用，需要开发大量的代码。ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。

• RabbitMQ
  使用erlang语言开发，性能较好，适合于企业级的开发。但是不利于做二次开发和维护。

• ActiveMQ
  历史悠久的Apache开源项目。已经在很多产品中得到应用，实现了JMS1.1规范，可以和springjms轻松融合，实现了多种协议，支持持久化到数据库，对队列数较多的情况支持不好。

• RocketMQ
  阿里巴巴的MQ中间件，由java语言开发，性能非常好，能够撑住双十一的大流量，而且使用起来 很简单。

• Kafka
  Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。

现在市面上用的最多的是 RocketMQ 和 Kafka 。Kafka大家应该不陌生，做大数据处理的时候，数据如果做在线运算，一般是将收集到的数据发往kafka，然后流向Spark，最终落地可视化。但是我们现在用的 Alibaba 组件，那么就应该首先使用 RocketMQ，而且，人家可是扛过双十一的。

RocketMQ的架构及概念

RocketMQ呢，是这么用滴，自身的存贮和kafka一样，有Topic（主题），它会把资源消息祖册到NameServer中，然消费者和生产者去调用，这有点像dubbo，dubbo就是把信息注册到zookeeper中。

丑丑的图：

好看一点的图：

如上图所示，整体可以分成4个角色，分别是：NameServer，Broker，Producer，Consumer。

• Broker
  Broker是RocketMQ的核心，负责消息的接收，存储，投递等功能。

• NameServer
  消息队列的协调者，Broker向它注册路由信息，同时Producer和Consumer向其获取路由信息。

• Producer
  消息的生产者，需要从NameServer获取Broker信息，然后与Broker建立连接，向Broker发送消息。

• Consumer
  消息的消费者，需要从NameServer获取Broker信息，然后与Broker建立连接，从Broker获取消息。

• Topic
  用来区分不同类型的消息，发送和接收消息前都需要先创建Topic，针对Topic来发送和接收消息。

• Message Queue
  为了提高性能和吞吐量，引入了Message Queue，一个Topic可以设置一个或多个MessageQueue，这样消息就可以并行往各个Message Queue发送消息，消费者也可以并行的从多个Message Queue读取消息。

• Message
  Message 是消息的载体。

• Producer Group
  生产者组，简单来说就是多个发送同一类消息的生产者称之为一个生产者组。

• Consumer Group
  消费者组，消费同一类消息的多个 consumer 实例组成一个消费者组。

在下一篇博文中，会讲述安装和使用。

本文地址：https://blog.csdn.net/qq_29064815/article/details/107367007