RocketMQ 学习笔记

简介：

RocketMQ（Metaq3.0版本更名）是一款分布式队列模型的消息中间件 特色以下：

1.保证消息顺序
2.支持消息拉取模式
3.高效的订阅者水平和扩展能力
4.实时的消息订阅机制
5.亿级的消息堆积能力

RocketMQ低延迟、高可靠、可伸缩、易于使用的消息中间件。具备如下特性：

1.强调集群无单点，可扩展，任意一点高可用，水平可扩展。
2.海量消息堆积能力，且堆积后写入低延迟。
3.支持上万个队列。（api丰富）
4.消息失败重试机制。
5.消息可查询。
6.开源社区活跃，成熟度高（双十一访问压力）。-- oceanbase
7.支持发布/订阅（Pub/Sub）和点对点（P2P）消息模型
8.在一个队列中可靠的先进先出（FIFO）和严格的顺序传递
9.支持拉（pull）和推（push）两种消息模式
10.单一队列百万消息的堆积能力
11.支持多种消息协议，如 JMS、MQTT 等
12.分布式高可用的部署架构,知足至少一次消息传递语义
13.提供 docker 镜像用于隔离测试和云集群部署
14.提供配置、指标和监控等功能丰富的 Dashboard

## 专业术语

Producer

消息生产者，生产者的做用就是将消息发送到
MQ，生产者自己既能够产生消息，如读取文本信息等。也能够对外提供接口，由外部应用来调用接口，再由生产者将收到的消息发送到
MQ。

Producer Group

生产者组，简单来讲就是多个发送同一类消息的生产者称之为一个生产者组。在这里能够不用关心，只要知道有这么一个概念便可。

Consumer

消息消费者，简单来讲，消费 MQ
上的消息的应用程序就是消费者，至于消息是否进行逻辑处理，仍是直接存储到数据库等取决于业务须要。

Consumer Group

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

Topic

Topic是一种消息的逻辑分类，好比说你有订单类的消息，也有库存类的消息，那么就须要进行分类，一个是订单 Topic 存放订单相关的消息，一个是库存 Topic 存储库存相关的消息。

Message

Message 是消息的载体。一个 Message 必须指定 topic，至关于寄信的地址。Message
还有一个可选的 tag 设置，以便消费端能够基于 tag 进行过滤消息。也能够添加额外的键值对，例如你须要一个业务 key 来查找 broker
上的消息，方便在开发过程当中诊断问题。

Tag

标签能够被认为是对 Topic 进一步细化。通常在相同业务模块中经过引入标签来标记不一样用途的消息。

Broker

Broker 是 RocketMQ 系统的主要角色，其实就是前面一直说的 MQ。Broker
接收来自生产者的消息，储存以及为消费者拉取消息的请求作好准备。

Name Server

Name Server 为 producer 和 consumer 提供路由信息。

RocketMQ 架构

由这张图能够看到有四个集群，分别是 NameServer 集群、Broker 集群、Producer 集群和
Consumer 集群：

1.  NameServer: 提供轻量级的服务发现和路由。 每一个 NameServer
    记录完整的路由信息，提供等效的读写服务，并支持快速存储扩展。

2.  Broker: 经过提供轻量级的 Topic 和 Queue
    机制来处理消息存储,同时支持推（push）和拉（pull）模式以及主从结构的容错机制。

3.  Producer：生产者，产生消息的实例，拥有相同 Producer Group 的 Producer
    组成一个集群。

4.  Consumer：消费者，接收消息进行消费的实例，拥有相同 Consumer Group 的  
    Consumer 组成一个集群。

简单说明一下图中箭头含义，从 Broker 开始，Broker Master1 和 Broker Slave1
是主从结构，它们之间会进行数据同步，即 Date Sync。同时每一个 Broker 与
NameServer 集群中的全部节
点创建长链接，定时注册 Topic 信息到全部 NameServer 中。

Producer 与 NameServer 集群中的其中一个节点（随机选择）创建长链接，按期从
NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Broker Master
创建长链接，且定时向 Broker 发送心跳。Producer 只能将消息发送到 Broker
master，可是 Consumer 则不同，它同时和提供 Topic 服务的 Master 和 Slave
创建长链接，既能够从 Broker Master 订阅消息，也能够从 Broker Slave 订阅消息。

RocketMQ 集群部署模式

1.  单 master 模式  
    也就是只有一个 master 节点，称不上是集群，一旦这个 master
    节点宕机，那么整个服务就不可用，适合我的学习使用。

2.  多 master 模式  
    多个 master 节点组成集群，单个 master 节点宕机或者重启对应用没有影响。  
    优势：全部模式中性能最高  
    缺点：单个 master
    节点宕机期间，未被消费的消息在节点恢复以前不可用，消息的实时性就受到影响。  
    **注意**：使用同步刷盘能够保证消息不丢失，同时 Topic 相对应的 queue
    应该分布在集群中各个节点，而不是只在某各节点上，不然，该节点宕机会对订阅该
    topic 的应用形成影响。

3.  多 master 多 slave 异步复制模式  
    在多 master 模式的基础上，每一个 master 节点都有至少一个对应的 slave。master  
    节点可读可写，可是 slave 只能读不能写，相似于 mysql 的主备模式。  
    优势： 在 master 宕机时，消费者能够从 slave
    读取消息，消息的实时性不会受影响，性能几乎和多 master 同样。  
    缺点：使用异步复制的同步方式有可能会有消息丢失的问题。

4.  多 master 多 slave 同步双写模式  
    同多 master 多 slave 异步复制模式相似，区别在于 master 和 slave
    之间的数据同步方式。  
    优势：同步双写的同步模式能保证数据不丢失。  
    缺点：发送单个消息 RT 会略长，性能相比异步复制低10%左右。  
    刷盘策略：同步刷盘和异步刷盘（指的是节点自身数据是同步仍是异步存储）  
    同步方式：同步双写和异步复制（指的一组 master 和 slave 之间数据的同步）

注意：要保证数据可靠，需采用同步刷盘和同步双写的方式，但性能会较其余方式低。

用户指南：

链接地址：https://files.cnblogs.com/files/ldy-blogs/RocketMQ_userguide.pdf