RocketMQ整理(一)

一.MQ的应用场景

  1. 应用解偶订单系统进行一次下单操作会依次调用支付、库存、物流系统。使用了MQ后,物流系统出了故障,只需要将支付和库存系统中的操作加入MQ,等待物流系统恢复,再发送消息给订单系统即可,就不会影响到订单系统。
  2. 流量削峰
    在这里插入图片描述
    在一个秒杀的场景下,服务器处理不了峰值每秒5k个请求数量,只需要将请求暂存到MQ,再定时拉取即可。
  3. 数据分发在这里插入图片描述
    如图所示,使用了MQ后,A系统将更加集成,因为不再需要关注谁来使用数据。

二.Why RocketMQ

RocketMQ的优点:

  • 单机吞吐量大:10W级别
  • 时效性优秀:ms级别
  • 机构优势:分布式架构
  • 扩展性:Java语言便携,对Java程序员扩展性高

三. 各个角色的介绍

1.消息生产者(Producer)
负责生产消息,一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式,同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息,单向发送不需要。

2 .消息消费者(Consumer)
负责消费消息,一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式:拉取式消费、推动式消费。

3.名字服务(Name Server)
名称服务充当路由消息的提供者。生产者或消费者能够通过名字服务查找各主题相应的Broker IP列表。多个Namesrv实例组成集群,但相互独立,没有信息交换。

4.代理服务器(Broker Server)
消息中转角色,负责存储消息、转发消息。代理服务器在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。代理服务器也存储消息相关的元数据,包括消费者组、消费进度偏移和主题和队列消息等。

5.主题(Topic)
表示一类消息的集合,每个主题包含若干条消息,每条消息只能属于一个主题,是RocketMQ进行消息订阅的基本单位。

6.消息(Message)
消息系统所传输信息的物理载体,生产和消费数据的最小单位,每条消息必须属于一个主题。

更多详情请见官方github docs
docs

四.架构设计

在这里插入图片描述
1.启动NameServer,NameServer起来后监听端口,等待Broker、Producer、Consumer连上来,相当于一个路由控制中心。
2.Broker启动,跟所有的NameServer保持长连接,定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后,NameServer集群中就有Topic跟Broker的映射关系。
3.收发消息前,先创建Topic,创建Topic时需要指定该Topic要存储在哪些Broker上,也可以在发送消息时自动创建Topic。
4.Producer与NameServer中的一个随机节点建立长链接获取Topic信息,再找到Broker的Master节点建立长链接并发送信息。
5.Consumer也类似,与NameServer中的一个随机节点建立长链接获取Topic信息,找到Broker的Master、Slave节点建立长链接开始消费消息,Consumer既可以从Master订阅消息,也可以从Slave订阅消息,订阅规则由Broker配置决定。

更多详情请见官方github docs
docs

五.Quick Start

安装、启动、集群的搭建就不多加赘述了,参考官方就好 Quick Start

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 游动-白 设计师:上身试试 返回首页