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

x33g5p2x  于11个月前 转载在 Spring  
字(2.3k)|赞(0)|评价(0)|浏览(140)

回溯

通过之前的博文,除了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是一个非常轻量级的消息系统,除了性能非常好之外,还是一个工作良好的分布式系统。

现在市面上用的最多的是 RocketMQKafka 。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 实例组成一个消费者组。

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

相关文章

热门文章

更多