关于java:RocketMq的认知

音讯队列是一种能够实现零碎异步通信的中间件，罕用于解决 零碎异步解耦和申请 (TPS) 削峰填谷 的问题。即它面向的是开发人员，而非终端用户能够间接应用的产品；

JMS 实质上是 JAVA API。在 JMS 中定义了 Producer，Consumer，Provider 三种角色，Producer 作为音讯的发送方，Consumer 作为音讯的接管方，Provider 作为服务的提供者，Producer 和 Consumer 统称为 Client。
JMS 定义了 点对点和公布订阅两种音讯模型，公布订阅模型中，通过 topic 对音讯进行路由，生产者能够将音讯发到指定的 topic，消费者订阅这个 topic 即可收到生产者发送的音讯。
一个生产者能够向一个或多个 topic 中发送音讯，一个消费者也能够生产一个或多个 topic 中的音讯，一个 topic 也能够有多个生产者或消费者，生产者和消费者只须要关联 topic，而不必关怀这音讯由谁发送或者生产。Provider 为每一个 topic 保护一个或多个 queue 来保留音讯，音讯在 queue 中是有序的，遵循先进先出的准则，不同 queue 间的音讯是无序的。
点对点模式中没有 topic 的概念，生产者间接将音讯发送到指定 queue，消费者也指定 queue 进行生产，音讯只能被一个消费者生产，不能够被多个消费者生产。Kafka 和 RocketMQ 都实现了或局部实现了 JMS 协定。

与 JMS 不同，AMQP 是一个应用层的网络传输协定，对报文格式进行定义，与开发语言无关。在 AMQP 中同样有生产者，消费者两种角色，音讯也是保留在 queue 中的。但不同于 JMS 用 topic 对音讯进行路由，AMQP 的路由形式由 exchange 和 binding 决定。

client 能够创立 queue，并在创立 queue 的同时告诉 exchange 这个 queue 承受合乎什么条件的音讯，这个条件即为 Bingding key。生产者发送音讯到 exchange 的时候会指定一个 router key，exchange 收到音讯后会与本人所保护的 Bingding key 做比拟，发送到符合条件的 queue 中。消费者在生产时指定 queue 进行生产。

RabbitMQ 实现了 AMQP 协定。

MQTT 协定是一种基于公布订阅的轻量级协定，反对 TCP 和 UDP 两种连贯形式，次要利用于即时通讯，小型设施，挪动利用等畛域。MQTT 中有发布者（Publish），订阅者（Subscribe）和代理服务器（Broker）三种角色。Broker 是服务的提供者，发布者和前两种协定中的生产者雷同，将音讯（Message）发送到 Broker，Subscribe 从 Broker 中获取音讯并做业务解决。
MQTT 的 Message 中固定音讯头（Fixed header）仅有 2 字节，开销极小，除此之外分为可变头（Variable header）和音讯体（payload）两局部。固定头中蕴含音讯类型，音讯级别，变长头的大小以及音讯体的总长度等信息。变长头则依据音讯类别，含有不同的标识信息。MQTT 容许客户端动静的创立主题，发布者与服务端建设会话（session）后，能够通过 Publish 办法发送数据到服务端的对应主题，订阅者通过 Subscribe 订阅主题后，服务端就会将主题中的音讯推送给对应的订阅者。

NameServer 是一个简直无状态节点，可集群部署，节点之间无任何信息同步，他们之间是独立的、并行的，各自保留了一份全副的 Broker、Topic 等集群信息。

非常简单的 Topic 路由注册核心;
反对 Broker 的动静注册与发现;
Broker 心跳检测;
为 Producer、Consumer 集群提供 Topic 路由性能（保护 Topic 跟 Broker 的映射关系);

Broker 次要负责音讯的存储、投递和查问以及服务高可用保障，蕴含四个次要的模块。

Remoting Module：整个 Broker 的实体，负责解决来自 clients 端的申请;
Client Manager：负责管理客户端 (Producer/Consumer) 和保护 Consumer 的 Topic 订阅信息;
Store Service：提供方便简略的 API 接口解决音讯存储到物理硬盘和查问性能;
HA Service：高可用服务，提供 Master Broker 和 Slave Broker 之间的数据同步性能;
Index Service：依据特定的 Message key 对投递到 Broker 的音讯进行索引服务，以提供音讯的疾速查问;

音讯公布的角色，反对分布式集群形式部署，无状态信息。

音讯生产的角色，反对分布式集群形式部署。反对以 push 推，pull 拉两种模式对音讯进行生产。同时也反对集群形式和播送形式的生产，它提供实时音讯订阅机制。

网络部署特点
—**-

NameServer 是一个简直无状态节点，可集群部署，节点之间无任何信息同步。
Broker 分为 Master 与 Slave，一个 Master 能够对应多个 Slave，然而一个 Slave 只能对应一个 Master。BrokerId 为 0 示意 Master，非 0 示意 Slave。每个 Broker 与 NameServer 集群中的所有节点建设长连贯，定时注册 Topic 信息到所有 NameServer。
Producer 与 NameServer 集群中的其中一个节点（随机抉择）建设长连贯，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Broker 节点中的 Master 建设长连贯 ， 且定时向 Master 发送心跳。Producer 齐全无状态，可集群部署。
Consumer 与 NameServer 集群中的其中一个节点（随机抉择）建设长连贯，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Broker 节点中的 Master、Slave 建设长连贯，且定时向 Master、Slave 发送心跳。

NameServer 是一个集群；
Broker 是一个集群，分为主节点和从节点，主节点能够读写，从节点只能读取音讯，并定时向所有的 NameServer 发送心跳信息，定时注册 Topic 信息到 NameServer 中；
Producer 是一个集群
Consumer 是一个集群
Producer 随机建设一个长连贯 NameServer，从中获取 Topic 信息，并与 Topic 所在 Master 建设长连贯、发送音讯、定时发送心跳信息。
Consumer 随机长连贯一个 NameServer，从中获取 Topic 信息，并与 Topic 所在 Master 或 Slaver 建设长连贯、发送音讯、定时发送心跳信息。

启动 NameServer，NameServer 起来后监听端口，期待 Broker、Producer、Consumer 连上来，相当于一个路由控制中心;
Broker 启动，跟所有的 NameServer 放弃长连贯，定时发送心跳包。心跳包中蕴含以后 Broker 信息 (IP+ 端口等) 以及存储所有 Topic 信息。注册胜利后，NameServer 集群中就有 Topic 跟 Broker 的映射关系;
收发音讯前，先创立 Topic，创立 Topic 时须要指定该 Topic 要存储在哪些 Broker 上，也能够在发送音讯时主动创立 Topic;
Producer 发送音讯，启动时先跟 NameServer 集群中的其中一台建设长连贯，并从 NameServer 中获取以后发送的 Topic 存在哪些 Broker[Master]上，轮询从队列列表中抉择一个队列，而后与队列所在的 Broker 建设长连贯从而向 Broker 发消息;
Consumer 跟 Producer 相似，跟其中一台 NameServer 建设长连贯，获取以后订阅 Topic 存在哪些 Broker 上，而后间接跟 Broker 建设连贯通道，开始生产音讯;

CommitLog：音讯主体以及元数据的存储主体，存储 Producer 端写入的音讯主体内容, 音讯内容不是定长的。

音讯次要是程序写入日志文件，当文件满了，写入下一个文件；
单个文件大小默认 1G，文件名长度为 20 位，右边补零，残余为起始偏移量，比方 00000000000000000000 代表了第一个文件，起始偏移量为 0，文件大小为 1G=1073741824；当第一个文件写满了，第二个文件为 00000000001073741824，起始偏移量为 1073741824，以此类推。

ConsumeQueue：音讯生产队列，引入的目标次要是进步音讯生产的性能，因为 RocketMQ 是 基于主题 topic 的订阅模式，音讯生产是针对主题进行的，如果要遍历 commitlog 文件中依据 topic 检索音讯是十分低效的。
Consumer 即可依据 ConsumeQueue 来查找待生产的音讯。其中，ConsumeQueue（逻辑生产队列）作为生产音讯的索引，保留了指定 Topic 下的队列音讯在 CommitLog 中的起始物理偏移量 offset，音讯大小 size 和音讯 Tag 的 HashCode 值。

consumequeue 文件能够看成是基于 topic 的 commitlog 索引文件，故 consumequeue 文件夹的组织形式如下：topic/queue/file 三层组织构造，具体存储门路为：$HOME/store/consumequeue/{topic}/{queueId}/{fileName}。同样 consumequeue 文件采取定长设计，每一个条目共 20 个字节，别离为 8 字节的 commitlog 物理偏移量、4 字节的音讯长度、8 字节 tag hashcode，单个文件由 30W 个条目组成，能够像数组一样随机拜访每一个条目，每个 ConsumeQueue 文件大小约 5.72M；

IndexFile：IndexFile（索引文件）提供了一种能够通过 key 或工夫区间来查问音讯的办法。Index 文件的存储地位是：$HOME/store/index/{fileName}，文件名 fileName 是以创立时的工夫戳命名的，固定的单个 IndexFile 文件大小约为 400M，一个 IndexFile 能够保留 2000W 个索引，IndexFile 的底层存储设计为在文件系统中实现 HashMap 构造，故 rocketmq 的索引文件其底层实现为 hash 索引;

在下面的 RocketMQ 的音讯存储整体架构图中能够看出，RocketMQ 采纳的是混合型的存储构造，即为 Broker 单个实例下所有的队列共用一个日志数据文件（即为 CommitLog）来存储;

RocketMQ 的混合型存储构造 (多个 Topic 的音讯实体内容都存储于一个 CommitLog 中) 针对 Producer 和 Consumer 别离采纳了数据和索引局部相拆散的存储构造，Producer 发送音讯至 Broker 端，而后 Broker 端应用同步或者异步的形式对音讯刷盘长久化，保留至 CommitLog 中;

只有音讯被刷盘长久化至磁盘文件 CommitLog 中，那么 Producer 发送的音讯就不会失落。正因为如此，Consumer 也就必定有机会去生产这条音讯。当无奈拉取到音讯后，能够等下一次音讯拉取，同时服务端也反对长轮询模式，如果一个音讯拉取申请未拉取到音讯，Broker 容许期待 30s 的工夫，只有这段时间内有新音讯达到，将间接返回给生产端。

这里，RocketMQ 的具体做法是，应用 Broker 端的后盾服务线程—ReputMessageService 不停地散发申请并异步构建 ConsumeQueue（逻辑生产队列）和 IndexFile（索引文件）数据。

Consumer 生产是以 ”Topic” 为粒度的，然而 CommitLog 是所有 Topic 音讯的汇总存储，这时候须要一个以 Topic 为维度的 commitLog 文件 offset 的索引，便于生产这个 Topic 下的数据，因而产生了 ConsumeQueue。相当于一个 Topic 下，有多个 MessageQueue 音讯队列，而后将音讯队列映射为 ConsumeQueue 音讯生产队列，供 Consumer 快捷生产这个 Topic 下的数据。

音讯生产者，位于用户的过程内，Producer 通过 NameServer 获取所有 Broker 的路由信息，依据负载平衡策略抉择将音讯发到哪个 Broker，而后调用 Broker 接口提交音讯。

生产者组，简略来说就是多个发送同一类音讯的生产者称之为一个生产者组。

音讯消费者，位于用户过程内。Consumer 通过 NameServer 获取所有 broker 的路由信息后，向 Broker 发送 Pull 申请来获取音讯数据。Consumer 能够以两种模式启动，播送（Broadcast）和集群（Cluster），播送模式下，一条音讯会发送给所有 Consumer，集群模式下音讯只会发送给一个 Consumer。

消费者组，和生产者相似，生产同一类音讯的多个 Consumer 实例组成一个消费者组。

Topic 用于将音讯按主题做划分，Producer 将音讯发往指定的 Topic，Consumer 订阅该 Topic 就能够收到这条音讯。Topic 跟发送方和生产方都没有强关联关系，发送方能够同时往多个 Topic 投放音讯，生产方也能够订阅多个 Topic 的音讯。在 RocketMQ 中，Topic 是一个上逻辑概念。音讯存储不会按 Topic 离开。

代表一条音讯，应用 MessageId 惟一辨认，用户在发送时能够设置 messageKey，便于之后查问和跟踪。一个 Message 必须指定 Topic，相当于寄信的地址。Message 还有一个可选的 Tag 设置，以便生产端能够基于 Tag 进行过滤音讯。也能够增加额定的键值对，例如你须要一个业务 key 来查找 Broker 上的音讯，不便在开发过程中诊断问题。

标签能够被认为是对 Topic 进一步细化。个别在雷同业务模块中通过引入标签来标记不同用处的音讯。

Broker 是 RocketMQ 的外围模块，负责接管并存储音讯，同时提供 Push/Pull 接口来将音讯发送给 Consumer。Consumer 可抉择从 Master 或者 Slave 读取数据。多个主 / 从组成 Broker 集群，集群内的 Master 节点之间不做数据交互。Broker 同时提供音讯查问的性能，能够通过 MessageID 和 MessageKey 来查问音讯。Borker 会将本人的 Topic 配置信息实时同步到 NameServer。

Topic 和 Queue 是 1 对多的关系 ， 一个 Topic 下能够蕴含多个 Queue，次要用于负载平衡。发送音讯时，用户只指定 Topic，Producer 会依据 Topic 的路由信息抉择具体发到哪个 Queue 上。Consumer 订阅音讯时，会依据负载平衡策略决定订阅哪些 Queue 的音讯。

RocketMQ 在存储音讯时会为每个 Topic 下的每个 Queue 生成一个音讯的索引文件，每个 Queue 都对应一个 Offset记录以后 Queue 中音讯条数。

NameServer 能够看作是 RocketMQ 的注册核心，它治理两局部数据：集群的 Topic-Queue 的路由配置；Broker 的实时配置信息。其它模块通过 Nameserv 提供的接口获取最新的 Topic 配置和路由信息。

Producer/Consumer：通过查问接口获取 Topic 对应的 Broker 的地址信息
Broker：注册配置信息到 NameServer，实时更新 Topic 信息到 NameServer

关于java:RocketMq的认知

MQ 相干介绍

三种音讯协定

JMS (Java Message Service)

AMQP(Advanced Message Quequing Protocol)[高级音讯队列协定]

MQTT(Message Queuing Telemetry Transport)

RocketMq- 架构组件

NameServer

BrokerServer

Producer

Consumer

连贯关系

工作流程

音讯存储整体架构

RocketMQ 专业术语

Producer

Producer Group

Consumer

Consumer Group

Topic

Message

Tag

Broker

Queue

Offset

NameServer