欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

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

程序员文章站 2022-03-26 19:02:01
这里写自定义目录标题回溯MQ介绍MQ的应用场景异步解耦流量削峰常用的MQ有哪些RocketMQ的架构及概念回溯通过之前的博文,除了Nacos的配置管理还没有讲解以外,其实已经可以初步的支持微服务的开发了,那么从这篇开始,就对开发过程中有可能(经常)用到的组件进行讲解吧,这篇讲解的是消息队列。ps(这篇看看就好,下一篇很很很重要) ps:主要是下一篇的一些坑是天坑,博主差点没爬出来!!MQ介绍MQ(Message Queue)是一种跨进程的通信机制,用于传递消息。通俗点说,就是一个先进先出的数据结构...

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

回溯

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

ps(这篇看看就好,下一篇很很很重要) ps:主要是下一篇的一些坑是天坑,博主差点没爬出来!!

MQ介绍

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

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

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

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

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

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

MQ的应用场景

异步解耦

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

Spring Cloud Alibaba - 消息队列(一)(RocketMQ)(介绍(这篇不重要,下一篇很重要,主要是下一篇坑太多了))
此架构下注册、邮件、短信三个任务全部完成后,才返回注册结果到客户端,用户才能使用账号登录。但是对于用户来说,注册功能实际只需要注册系统存储用户的账户信息后,该用户便可以登录,而后续的注册短信和邮件不是即时需要关注的步骤。

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

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

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

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

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

流量削峰

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

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

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

常用的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中。

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

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

如上图所示,整体可以分成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