RocketMQ进阶1_架构与集群部署模式
1. 术语
-
Producer
消息生产者。生产者的作用就是将消息发送到 MQ。
-
Producer Group
生产者组。
-
Consumer
消息消费者。
-
Consumer Group
消费者组。
-
Topic
一种消息的逻辑分类，比如说你有订单类的消息，也有库存类的消息，那么就需要进行分类，一个是订单 Topic 存放订单相关的消息，一个是库存 Topic 存储库存相关的消息。
-
Message
Message 是消息的载体。一个 Message 必须指定 topic，相当于寄信的地址。Message 还有一个可选的 tag 设置，以便消费端可以基于 tag 进行过滤消息。
-
Tag
标签可以被认为是对 Topic 进一步细化。一般在相同业务模块中通过引入标签来标记不同用途的消息。
-
Broker
Broker 接收来自生产者的消息，储存以及为消费者拉取消息的请求做好准备。
-
Name Server
Name Server 为 producer 和 consumer 提供路由信息。
2. RocketMQ架构
RocketMQ物理部署结构：
有四个集群，分别是 NameServer 集群、Broker 集群、Producer 集群和 Consumer 集群：
-
NameServer
提供轻量级的服务发现和路由。
每个 NameServer 记录完整的路由信息，提供相应的读写服务，并支持快速存储扩展。
-
Broker
通过提供轻量级的 Topic 和 Queue 机制来处理消息存储，同时支持推（push）和拉（pull）模式以及主从结构的容错机制。
-
Producer
生产者，产生消息的实例，拥有相同 Producer Group 的 Producer 组成一个集群。
-
Consumer
消费者，接收消息进行消费的实例，拥有相同 Consumer Group 的 Consumer 组成一个集群。
RocketMQ 的部署结构有以下特点：
- Name Server 是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
- Broker 分为 Master 与 Slave，一个 Master（主人）可以对应多个 Slave(奴隶)，但是一个 Slave 只能对应一个 Master，Master 与 Slave 的对应关系通过指定相同的 BrokerName，不同的 BrokerId 来定义，BrokerId 为0表示 Master，非0表示 Slave。Master 也可以部署多个，每个 Broker 与 Name Server 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 Name Server。
- 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 配置决定。
重点说明的部分：
-
Producer
生产者支持分布式部署。分布式生产者通过多种负载均衡模式向 Broker 集群发送消息。发送过程支持快速失败并具有低延迟。
-
NameServer
提供轻量级服务和路由，每个 Name Server 记录完整的路由信息，提供相应的读写服务，支持快速存储扩展。主要包括两个功能：
- 代理管理，NameServer 接受来自 Broker 集群的注册，并提供检测代理是否存在的心跳机制。
- 路由管理，NameServer 将保存有关代理集群的全部路由信息以及客户端查询的队列信息。
RocketMQ 客户端(生产者/消费者)会从 NameServer 查询队列路由信息。客户端通过如下方式之一找到NameServer地址：
- 编程方式，如：producer.setNamesrvAddr("ip:port")
- Java 选项，如：rocketmq.namesrv.addr
- 环境变量，如：NAMESRV_ADDR
- HTTP 端点
-
Broker
- Broker 通过提供轻量级的 Topic 和 Queue 机制来进行消息存储。
- Broker 支持 Push 和 Pull 模式，包含容错机制，并且提供了强大的峰值填充和以原始时间顺序累计数千亿条消息的能力。
- Broker 还提供灾难恢复，丰富的指标统计数据和警报机制，而传统的消息传递系统都缺乏这些机制。
RocketMQ逻辑部署结构：
-
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 下的每个实例都消费全量数据。
3. RocketMQ集群部署模式
3.1 单 master 模式
不算是集群模式，只有一个 master 节点，一旦这个 master 节点宕机，那么整个服务就不可用，适合个人学习使用。
3.2 多 master 模式
多个 master 节点组成集群，单个 master 节点宕机或者重启对应用没有影响。
- 优点：所有模式中性能最高
- 缺点：单个 master 节点宕机期间，未被消费的消息在节点恢复之前不可用，消息的实时性就受到影响。
注意：使用同步刷盘可以保证消息不丢失，同时每个 Topic 应该均匀分布在集群中每个节点，而不是只在某个节点上，否则，该节点宕机就会对订阅该 topic 的应用造成影响。
3.3 多 master 多 slave 异步复制模式
在多 master 模式的基础上，每个 master 节点都有至少一个对应的 slave。master节点可读可写，但是 slave 只能读不能写，类似于 mysql 的主备模式。
- 优点：在 master 宕机时，消费者可以从 slave 读取消息，消息的实时性不会受影响，性能几乎和多 master 一样。
- 缺点：使用异步复制的同步方式有可能会有消息丢失的问题。
3.4 多 master 多 slave 同步双写模式
同多 master 多 slave 异步复制模式类似，区别在于 master 和 slave 之间的数据同步方式。
- 优点：同步双写的同步模式能保证数据不丢失。
- 缺点：发送单个消息 RT 会略长，性能相比异步复制低10%左右。
刷盘策略：同步刷盘和异步刷盘（指的是节点自身数据是同步还是异步存储）
同步方式：同步双写和异步复制（指的 master 和其 slave 之间数据的同步）
注意：要保证数据可靠，需采用同步刷盘和同步双写的方式，但性能会较其他方式低。
