RocketMQ
目录
官方文档
相关博客
RocketMQ架构上分四部分构成
Apache RocketMQ is a distributed messaging and streaming platform with low latency, high performance and reliability, trillion-level capacity and flexible scalability. It consists of four parts: name servers, brokers, producers and consumers. Each of them can be horizontally extended without a single Point of Failure. As shown in screenshot above.
Producer
负责生产消息，通过MQ的负载均衡模块选择Broker集群队列进行消息投递，投递过程支持快速失败并且低延迟。
Producers support distributed deployment. Distributed Producers send messages to the Broker cluster through multiple load balancing modes. The sending processes support fast failure and have low latency.
Consumer
消息消费者会从Broker服务器中获取消息，并对消息进行业务才处理
Consumers support distributed deployment in the Push and Pull model as well. It also supports cluster consumption and message broadcasting. It provides real-time message subscription mechanism and can meet most consumer requirements. RocketMQ’s website provides a simple quick-start guide to interested users.
Broker
Broker主要用于存储和转发消息
Brokers take care of message storage by providing lightweight TOPIC and QUEUE mechanisms. They support the Push and Pull model, contains fault tolerance mechanism (2 copies or 3 copies), and provides strong padding of peaks and capacity of accumulating hundreds of billion messages in their original time order. In addition, Brokers provide disaster recovery, rich metrics statistics, and alert mechanisms, all of which are lacking in traditional messaging systems.
NameServer
是一个轻量的注册中心，对Broker及路由信息进行管理
Name Servers provide lightweight service discovery and routing. Each Name Server records full routing information, provides corresponding reading and writing service, and supports fast storage expansion.
NameServer主要有以下两个功能
Broker管理：接受Broker集群的注册信息并保存作为路由信息的基本数据，提供心跳检测机制，检查Broker是否存活
路由信息管理：保存Broker集群整个路由信息和用于客户端查询的队列信息，Producer和Consumer通过NameServer获取整个Broker集群的路由信息，进行消息的投递和消费。
Broker为证明自己存活，会将最新信息以心跳包的方式上报给NameServer，每30秒将BrokerId， Broker地址，Broker名称，所属集群名称等信息发送给NameServer，NameServer收到心跳包后会记录Broker的最新存活时间
由于Broker关机，宕机或网络抖动等原因，NameServer会没有收到Broker的心跳，NameServer中有一个定时任务，每隔10秒扫描一次Broker表，查看每一个Broker的最新心跳时间戳距离当前时间是否超过120秒，如果超过，则会判定Broker时效，将该Broker从列表中剔除
RocketMQ的路由发现采用的是PULL模型，当Topic路由信息出现变化时，NameServer不会主动推送给客户端，客户端默认每30秒会从NameServer中拉取一次最新的路由
客户端首先产生一个随机数，与NameServer节点数量取模，然后进行连接，如果连接失败，则会采用round-robin策略，逐个尝试与其他节点连接
Broker有几个子模块：
客户端管理器：管理客户端，并且维护consumer的的topic订阅信息
存储服务：提供简单api处理消息存储磁盘及消息查询功能
高可用服务：提供master和slave之间的消息同步功能
索引服务：为消息构建索引，并提供消息查找功能
Broker server is responsible for message store and delivery, message query, HA guarantee, and so on.
As shown in image below, Broker server has several important sub modules:
- Remoting Module, the entry of broker, handles the requests from clients.
- Client Manager, manages the clients (Producer/Consumer) and maintains topic subscription of consumer.
- Store Service, provides simple APIs to store or query message in physical disk.
- HA Service, provides data sync feature between master broker and slave broker.
- Index Service, builds index for messages by specified key and provides quick message query.
Broker内部维护Topic的Queue，一个Topic分散在多个Broker
Topic有两种模式进行创建，创建Topic时除TopicName外，还需配置读写队列数量及perm
创建模式
集群模式：创建的Topic在集群所有Broker中的Queue数量相同
Broker模式：创建的Topic指定存在哪些Broker中，并进行Queue数量设置
读写队列
物理上讲读写队列是同一个队列，读写队列是逻辑上进行区分，一般读写队列数量是相同的。
读写队列如设置不同数量，会存在消息不被消费或消费不到的问题，之所以如此设计，是为了方便Topic的缩容。
例如16个Queue的Topic如何缩容为8个Queue的Topic，如果读写队列同时减少为8，此时剩余的8个Queue里的消息将不被消费，如果先将写队列改为8，消费队列继续为16，等到剩下的8个队列都消费完了，再将消费队列改为8，这样就不会丢失消息。
perm
2表示只写，4表示只读，6表示读写
1）单Master
单机模式, 即只有一个Broker
2）多Master模式
组成一个集群, 集群每个节点都是Master节点
3）多Master多Slave模式
每个Master配置一个Slave，集群中存在多对Master-Slave，生产常用该部署方式。
| 单Master | 多Master | 多Master多Slave模式 | |
| 优点 | 成本低 | 性能高 | 节点宕机可切换至Slave继续消费，保证可用性 |
| 缺点 | 存在单点问题，不推荐 | 宕机节点消息不能被消费 | 成本高，性能较低 |
生产者将消息发送给Broker，此时Broker是将消息写入内存中，然后根据不同的刷盘策略，将消息持久化到磁盘中。
同步刷盘：当消息持久化当Broker磁盘后，消息才算是写入成功，Broker返回成功标识给到客户端
异步刷盘：当消息写入内存中，消息就算是写入成功，Broker返回成功标识给到客户端，不等待消息持久化到磁盘
| 同步刷盘 | 异步刷盘 | |
| 优点 | 保证消息持久化成功 | 吞吐量较高 |
| 缺点 | 吞吐量较低 | 宕机可能引起消息丢失 |
复制策略是Broker的master和slave之间的数据同步方式，分同步双写和异步复制
同步双写：只有master和slave都写成功以后，才会向客户端返回成功
异步复制：消息写入master成功后，就返回给客户端成功，不会等待Slave写入成功
| 同步双写 | 异步复制 | |
| 优点 | slave消息不会丢失 | 性能较同步双写高 |
| 缺点 | 吞吐量、性能较异步复制低10% | 节点宕机可能导致消息丢失 |
6. 问题
某个Consumer不消费消息
1. Consumer数量应该小于等于订阅Topic的Queue数量，如果超出Queue数量，多出的Consumer将不能消费消息
Q：为什么用RocketMQ而不是其他MQ框架
A：见消息中间件-选型
Q：RocketMQ的总体架构
A：见1
Q：Rocket有哪几种部署类型？分别有什么特点？
A：见3.1
Q：Rocket有哪几种部署类型？分别有什么特点？
A：见1