RocketMQ 核心概念 部署结构 数据结构 集群部署模式

1.RocketMQ 简介

• 是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点。
• Producer、Consumer、队列都可以分布式。
• Producer 向一些队列轮流发送消息，队列集合称为 Topic，Consumer 如果做广播消费，则 一个 consumer实例消费这个 Topic 对应的所有队列，如果做集群消费，则多个 Consumer实例平均消费这个 topic 对应的队列集合。
• 能够保证严格的消息顺序。
• 提供丰富的消息拉取模式
• 高效的订阅者水平扩展能力
• 实时的消息订阅机制
• 亿级消息堆积能力
• 较少的依赖

2.关键概念

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 进一步细化。将Topic理解为书，那么Tag可以理解为书的目录，例如：
Topic：订单交易
Tag：
       订单交易-创建
       订单交易-付款
       订单交易-完成

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

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

3.RocketMQ 物理部署结构

如上图所示， RocketMQ的部署结构有以下特点：

• Name Server是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
• Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。
• Producer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
• Consumer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向 Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。

4.RocketMQ 逻辑部署结构

如上图所示，RocketMQ的逻辑部署结构有Producer和Consumer两个特点。
Producer Group
用来表示一个发送消息应用，一个Producer Group下包含多个Producer实例，可以是多台机器，也可以是一台机器的多个进程，或者一个进程的多个Producer对象。一个Producer Group可以发送多个Topic消息，Producer Group作用如下：

• 标识一类Producer
• 可以通过运维工具查询这个发送消息应用下有多个Producer实例
• 发送分布式事务消息时，如果Producer中途意外宕机，Broker会主动回调Producer Group内的任意一台机器来确认事务状态。

Consumer Group
用来表示一个消费消息应用，一个Consumer Group下包含多个Consumer实例，可以是多台机器，也可以是多个进程，或者是一个进程的多个Consumer对象。一个Consumer Group下的多个Consumer以均摊方式消费消息，如果设置为广播方式，那么这个Consumer Group下的每个实例都消费全量数据。

5.RocketMQ 数据结构

RocketMQ采取了一种数据与索引分离的存储方法。有效降低文件资源、IO资源，内存资源的损耗。即便是阿里这种海量数据，高并发场景也能够有效降低端到端延迟，并具备较强的横向扩展能力

|-- abort
|-- checkpoint
|-- config
| |-- consumerOffset.json
| |-- consumerOffset.json.bak
| |-- delayOffset.json
| |-- delayOffset.json.bak
| |-- subscriptionGroup.json
| |-- subscriptionGroup.json.bak
| |-- topics.json
| `-- topics.json.bak
|-- commitlog
| |-- 00000003384434229248
| |-- 00000003385507971072
| `-- 00000003386581712896
`-- consumequeue
|-- %DLQ%ConsumerGroupA
| `-- 0
| `-- 00000000000006000000
|-- %RETRY%ConsumerGroupA
| `-- 0
| `-- 00000000000000000000
|-- %RETRY%ConsumerGroupB
| `-- 0
| `-- 00000000000000000000
|-- SCHEDULE_TOPIC_XXXX
| |-- 2
| | `-- 00000000000006000000
| |-- 3
| | `-- 00000000000006000000
|-- TopicA
| |-- 0
| | |-- 00000000002604000000
| | |-- 00000000002610000000
| | `-- 00000000002616000000
| |-- 1
| | |-- 00000000002610000000
| | `-- 00000000002616000000
|-- TopicB
| |-- 0
| | `-- 00000000000732000000
| |-- 1
| | `-- 00000000000732000000
| |-- 2
| | `-- 00000000000732000000

6.RocketMQ 集群部署模式

单个Master
只有一个 master 节点，一旦这个 master 节点宕机，那么整个服务就不可用，适合个人学习使用

多 Master 模式
一个集群无 Slave，全是 Master，例如 2 个 Master 或者 3 个 Master
优点：配置简单，单个Master宕机或重启维护对应用无影响。

缺点：单个 master 节点宕机期间，未被消费的消息在节点恢复之前不可用，消息的实时性就受到影响

启动顺序
       1).先启动NameServer
       2).在机器A，启动第一个Master
       3).在机器B，启动第二个Master

多Master 多Slave 异步复制模式
在多 master 模式的基础上，每个 master 节点都有至少一个对应的 slave。master
节点可读可写，但是 slave 只能读不能写，类似于 mysql 的主备模式

优点： 在 master 宕机时，消费者可以从 slave 读取消息，消息的实时性不会受影响，性能几乎和多 master 一样

缺点：Master 宕机，磁盘损坏情况，会丢失少量消息

启动顺序
       1).先启动NameServer
       2).在机器A，启动第一个Master
       3).在机器B，启动第二个Master
       4).在机器C，启动第一个Slave
       5).在机器D，启动第二个Slave

多Master 多Slave同步双写模式
同多 master 多 slave 异步复制模式类似，区别在于 master 和 slave 之间的数据同步方式。采用同步双写方式，主备都写成功，向应用返回成功

优点：同步双写的同步模式能保证数据不丢失

缺点：性能比异步复制模式略低，大约低 10%左右，发送单个消息的 RT会略高

启动顺序
       1).先启动NameServer
       2).在机器A，启动第一个Master
       3).在机器B，启动第二个Master
       4).在机器C，启动第一个Slave
       5).在机器D，启动第二个Slave

以上 Broker 与 Slave 配对是通过指定相同的brokerName 参数来配对，Master的 BrokerId 必须是0，Slave 的BrokerId 必须是大与 0 的数。另外一个 Master下面可以挂载多个 Slave，同一 Master下的多个 Slave通过指定不同的 BrokerId 来区分