RocketMQ

一、MQ概述

1.1、RocketMQ简介

RocketMQ是一个开源的分布式消息中间件，最初由阿里巴巴集团开发。它的设计目标是为了在高并发、高吞吐量的场景下，实现可靠的消息传输，并且具有良好的可伸缩性和可扩展性。

1.2、MQ用途

限流削峰
异步与解耦
数据分发

限流削峰
MQ可以将系统的超量请求暂存其中，以便系统后期可以慢慢进行处理，从而避免了请求的丢失或系统被压垮。

异步解耦

上游系统对下游系统的调用若为同步调用，则会大大降低系统的吞吐量与并发度，且系统耦合度太高、而异步调用则会解决这些问题。所以两层之间若要实现由同步到异步的转化，一般性做法就是，在这两层间添加一个MQ层。

数据分发

1.3、常见MQ产品

RabbitMQ
RabbitMQ是使用ErLang语言开发的一款MQ产品。其吞吐量较Kafka与RocketMQ要低，且由于其不是Java语言开发，所以公司内部对其实现定制化开发难度较大。
Kafka
Kafka是使用Scala/Java语言开发的一款MQ产品。其最大的特点就是高吞吐量，常用于大数据领域的实时计算、日志采集等场景。其没有遵循任何常见的MQ协议，而是使用自研协议。
RocketMQ
RocketMQ是使用Java语言开发的一款MQ产品。经过数年阿里双11的考验，性能与稳定性非常高。其没有遵循任何常见的MQ协议，而是使用自研协议。

1.4、常见MQ协议

JMS:

java messageing service(java消息服务),是Java平台上面有关MOM(message originted middleware)面向消息中间件的技术规范,便于java应用程序进行消息交换,并且提供标准的产生,发送,接受信息的接口,适用于ActiveMQ,现在市场上已经不再使用ActiveMQ进行维护产品了,发稿时间为2021年7月22日12:58:42

STOP:

面向文本的消息协议,也是MOM设计的简单文本协议,STOP提供一种可以互操的连接方式,允许客户与任意的STOP消息代理进行连接,也是ActiveMQ的典型实现,RabbitMQ可以通过插件实现

AMQP:

高级消息队列协议提供消息服务的应用层标准,也是MOM设计,不受是不是同一产品,统一语言的限制,是RabbitMQ的典型实现

MQTT:

是IBM开发的一个及时通讯协议,二进制协议,主要用服务器或者低功效的,服务器与物联网的连接协议.通过插件RabbitMQ,且支持所有平台,非常广泛

二、RocketMQ

RocketMQ的核心概念

2.1 分组(Group)

生产者：标识发送同一类消息的Producer，通常发送逻辑一致。发送普通消息的时候，仅标识使用，并无特别用处。主要作用用于事务消息：
消费者：标识一类Consumer的集合名称，这类Consumer通常消费一类消息（也称为Consumer Group），且消费逻辑一致。同一个Consumer Group下的各个实例将共同消费topic的消息，起到负载均衡的作用。

2.2 主题（Topic）
标识RocketMQ中一类消息的逻辑名字，消息的逻辑管理单位。无论消息生产还是消费，都需要指定Topic。主题主要用于区分消息的种类：一个生产者可以发送消息给一个或者多个Topic，消息的消费者也可以订阅一个或者多个Topic消息。

2.3 标签(Tag)

标签为消息设置的标签，用于同一主题下区分不同类型的消息。来自同一业务单元的消息，可以根据不同业务目的在同一主题下设置不同标签。
Topic是消息的一级分类，Tag是消息的二级分类

2.4 消息队列（Message Queue）

存储消息的物理实体。 一个Topic中可以包含多个Queue，每个Queue中存放的就是该Topic的消息。 一个Topic的Queue也被称为一个Topic中消息的分区（Partition）。 一个Topic的Queue中的消息只能被一个消费者组中的一个消费者消费。 一个Queue中的消息不允许同一个消费者组中的多个消费者同时消费。

分片不同于分区。在RocketMQ中，分片指的是存放相应Topic的Broker。每个分片中会创建出相应数量的分区，即Queue，每个Queue的大小都是相同的。

2.5 消息表示（MessageId/key）

RocketMQ中每个消息拥有唯一的MessageId，且可以携带具有业务标识的key，以方便对消息的查询，需要注意，message有2个：在生产者send()消息时会自动生成一个MessageId，当消息到达broker后，broker也会自动生成一个messageId(Offset MsgId)。msgId OffsetMsgId与key都称为消息标识/

msgId：由produce端r生成，生成规则为：
producerIp + 进程pid + messageClientIdSetter类的classLoader的hashcode + 当前时间 + automicInteger自增计数器

OffsetMsgId：由broker端生成，生成规则为: beokerIp + 物理分区的Offset

key：由用户指定业务相关的唯一标识。

RocketMq中的角色

2.1 NameServer

NameServer是一个broker与topic路由注册中心,支持broker的动态注册与发现

主要包括两个功能：

Broker管理：接受Broker集群的注册信息并且保存下来作为路由信息的基本数据；提供心跳检测机制，检查Broker是否还存活。

路由信息管理：每个NameServer中都保存着Broker集群的整个路由信息和用于客户端查询的队列信息。Producer和Conumser通过NameServer可以获取整个Broker集群的路由信息，从而进行消息的投递和消费。NameServer可以获取整个Broker集群的路由信息，从而进行消息的投递和消费。

路由注册

Name Server既然是注册中心，那么是如何完成注册的呢？
NameServer通常也是以集群的方式部署，不过，NameServer是无状态的，即NameServer集群中的各个节点间是无差异的，各节点间相互不进行信息通讯。
那各节点中的数据是如何进行数据同步的呢？在Broker节点启动时，轮询NameServer列表，与每个NameServer节点建立长连接，发起注册请求。在NameServer内部维护着⼀个Broker列表，用来动态存储Broker的信息。

Broker节点为了证明自己是活着的，为了维护与NameServer间的长连接，会将最新的信息以心跳包的方式上报给NameServer，每30秒发送一次心跳。心跳包中包含
BrokerId、Broker地址(IP+Port)、Broker名称、Broker所属集群名称等等。NameServer在接收到心跳包后，会更新心跳时间戳，记录这个Broker的最新存活时间。

NameServer集群优缺点:

优点: NameServer集群搭建简单，扩容简单。 缺点:
对于broker，必须明确指出所有NameServer地址。否则未指出的将不会注册。也正因为如此，NameServer并不能随便扩容。因为，若broker不重新配置，新增的NameServer对于broker来说是不可见的，其不会像这个NameServer进行注册。

路由剔除

由于Broker关机、宕机或网络抖动等原因，NameServer没有收到Broker的心跳，NameServer可能会将其从Broker列表中剔除。
NameServer中有⼀个定时任务，每隔10秒就会扫描⼀次Broker表，查看每一个Broker的最新心跳时间戳距离当前时间是否超过120秒，如果超过，则会判定Broker失效，然后将其从Broker列表中剔除。

路由发现
RocketMQ的路由发现采用的是Pull模型。当Topic路由信息出现变化时，NameServer不会主动推送给客户端，而是客户端定时拉取Topic最新的路由。 默认客户端每30秒会拉取一次最新的路由。

push模型：
推送模型，实时性较好，是一个发布订阅模型，需要维护一个长连接，而长连接的维护是需要资源成本的，该模型适合于的场景:
实时性要求高，client数量不多，server数据变化频繁

pull模型：
拉取模型，存在的问题是，实时性较差。

long polling模型：
长轮询模型，是对push 与pull模型的整合，充分利用了两种模型的优势，屏蔽了他们的劣势。

客户端NameServer选择策略
这里的客户端指的是producer和consumer
首先采用的是随机策略进行选择，失败后采用的是轮询策略

2.2 主机（broker）

RocketMQ的核心，用于暂存和传输消息。

2.3 消息（Message）

消息：生产或消费的数据，对于RocketMQ来说，消息就是字节数组。

2.4 生产者（producer）

生产者：也称为消息发布者，负责生产并发送消息至RocketMQ。

2.5 消费者（consumer）

消费者：也称为消息订阅者，负责从RocketMQ接收并消费消息