*本文涉及：
RocketMQ基本概念
目录
RocketMQ
架构
RockteMQ架构
生产者 Producer
发布消息的角色。Producer通过 MQ 的负载均衡模块选择相应的 Broker 集群队列进行消息投递，投递的过程支持快速失败和重试。
消费者 Consumer
消息消费的角色。
- 支持以推（push），拉（pull）两种模式对消息进行消费。
- 同时也支持集群方式和广播方式的消费。
- 提供实时消息订阅机制，可以满足大多数用户的需求。
注册中心 NameServer
NameServer是一个简单的 Topic 路由注册中心，支持 Topic、Broker 的动态注册与发现。
主要包括两个功能：
- Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；
- 路由信息管理，每个NameServer将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。Producer和Consumer通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。
NameServer通常会有多个实例部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，客户端仍然可以向其它NameServer获取路由信息。
代理服务器 Broker
Broker主要负责消息的存储、投递和查询以及服务高可用保证。
NameServer几乎无状态节点，因此可集群部署，节点之间无任何信息同步。Broker部署相对复杂。
在 Master-Slave 架构中，Broker 分为 Master 与 Slave。一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。Master 与 Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。
- 每个 Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer。
- Producer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取Topic路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态。
- Consumer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master、Slave 建立长连接，且定时向 Master、Slave发送心跳。Consumer 既可以从 Master 订阅消息，也可以从Slave订阅消息。
消息模型
Apache RocketMQ消息模型
如上图所示，Apache RocketMQ 中消息的生命周期主要分为消息生产、消息存储、消息消费这三部分。
生产者生产消息并发送至 Apache RocketMQ 服务端，消息被存储在服务端的主题中，消费者通过订阅主题消费消息。
消息生产
- 生产者（Producer） 创建消息并指定目标主题（Topic）。
- 序列化：生产者将业务对象转化为字节流形式的消息数据。
- 发送消息：生产者将消息发送到RocketMQ的Broker服务器。根据业务需求，可以选择同步或异步发送方式，以及事务消息、顺序消息、定时消息等不同类型的消息发送方式。
- 路由：Broker的NameServer会根据Topic信息指引消息到正确的Broker节点。
消息存储
- Broker接收：Broker接收到消息后，首先对其进行有效性检查。
- 持久化存储：Broker将消息持久化存储在CommitLog中，这是RocketMQ的消息主存储区，所有消息按照严格的时间顺序追加写入。
- 建立索引：同时，Broker还会在ConsumeQueue（消费队列）中为每个主题和消费队列创建索引，存储指向CommitLog中消息的物理偏移量和其它元数据，方便快速定位和消费消息。
- 设置消息有效期：RocketMQ支持消息有效期管理，超过有效期的消息会被自动清除。
消息消费
- 消费者订阅：消费者（Consumer）订阅感兴趣的Topic和消费策略。
- 拉取消息：消费者向Broker拉取消息，Broker根据消费进度和消费模式（集群消费、广播消费、顺序消费等）返回消息。
- 消费确认：消费者成功处理消息后，可以选择向Broker发送消费确认（acknowledgement），以便Broker更新消息消费状态。
- 消息重试：若消费者处理消息失败，Broker会根据重试策略将消息重新放回队列等待再次消费，直至达到最大重试次数或者消息变为死信。
传输模型
发布订阅模型
RocketMQ 使用的传输模型为发布订阅模型，相比队列模型的匿名消费方式，发布订阅模型中消费方都会具备的身份，一般叫做订阅组（订阅关系），不同订阅组之间相互独立不会相互影响。
基于独立身份的设计，同一个主题内的消息可以被多个订阅组处理，每个订阅组都可以拿到全量消息。因此发布订阅模型可以实现一对多通信。
PS：官方文档指出了RocketMQ使用的是发布订阅模型。但是网上检索到的信息均说支持点对点与发布订阅模型，均是使用队列（Queue）来实现点对点消息传递，那么说支持点对点模型也可以。
