MQ相干介绍

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

三种音讯协定

JMS (Java Message Service)

  • 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 协定。

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

与 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(Message Queuing Telemetry Transport)

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

RocketMq-架构组件

NameServer

NameServer是一个简直无状态节点，可集群部署，节点之间无任何信息同步，他们之间是独立的、并行的，各自保留了一份全副的 Broker、Topic 等集群信息。
  • 非常简单的 Topic 路由注册核心;
  • 反对 Broker 的动静注册与发现;
  • Broker 心跳检测;
  • 为 Producer、Consumer 集群提供 Topic 路由性能（保护Topic跟Broker的映射关系);

BrokerServer

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的音讯进行索引服务，以提供音讯的疾速查问;

Producer

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

Consumer

音讯生产的角色，反对分布式集群形式部署。反对以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下的数据。

RocketMQ专业术语

Producer

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

Producer Group

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

Consumer

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

Consumer Group

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

Topic

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

Message

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

Tag

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

Broker

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

Queue

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

Offset

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

NameServer

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

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