架构-RocketMQ架构详解

概述

RocketMQ一个纯java、分布式、队列模型的开源消息中间件，前身是MetaQ，是阿里研发的一个队列模型的消息中间件，后开源给apache基金会成为了apache的顶级开源项目，具有高性能、高可靠、高实时、分布式特点。
RocketMQ是阿里开源的分布式消息中间件，跟其它中间件相比，RocketMQ的特点是纯JAVA实现；集群和HA实现相对简单；在发生宕机和其它故障时消息丢失率更低。

RocketMQ架构

● Producer：消息生产者
● Consumer：消费者
● Broker：MQ 服务，负责接收、分发消息
● NameServer：负责 MQ 服务之间的协调
整体架构中包含四种角色
● Producer ：消息发布的角色，Producer 通过 MQ 的负载均衡模块选择相应的 Broker 集群队列进行消息投递，投递的过程支持快速失败并且低延迟。
● Consumer ：消息消费的角色，支持以 push 推，pull 拉两种模式对消息进行消费。
● NameServer ：名字服务是一个非常简单的 Topic 路由注册中心，其角色类似 Dubbo 中的 zookeeper ，支持 Broker 的动态注册与发现。
● BrokerServer ：Broker 主要负责消息的存储、投递和查询以及服务高可用保证

Producer
消息生产者，位于用户的进程内，Producer通过NameServer获取所有Broker的路由信息，根据负载均衡策略选择将消息发到哪个Broker，然后调用Broker接口提交消息。
Producer Group
生产者组，简单来说就是多个发送同一类消息的生产者称之为一个生产者组。
Consumer
消息消费者，位于用户进程内。Consumer通过NameServer获取所有broker的路由信息后，向Broker发送Pull请求来获取消息数据。Consumer可以以两种模式启动，广播（Broadcast）和集群（Cluster），广播模式下，一条消息会发送给所有Consumer，集群模式下消息只会发送给一个Consumer。
Consumer Group
消费者组，和生产者类似，消费同一类消息的多个 Consumer 实例组成一个消费者组。
Topic
Topic用于将消息按主题做划分，Producer将消息发往指定的Topic，Consumer订阅该Topic就可以收到这条消息。Topic跟发送方和消费方都没有强关联关系，发送方可以同时往多个Topic投放消息，消费方也可以订阅多个Topic的消息。在RocketMQ中，Topic是一个上逻辑概念。消息存储不会按Topic分开。
Message
代表一条消息，使用MessageId唯一识别，用户在发送时可以设置messageKey，便于之后查询和跟踪。一个 Message 必须指定 Topic，相当于寄信的地址。Message 还有一个可选的 Tag 设置，以便消费端可以基于 Tag 进行过滤消息。也可以添加额外的键值对，例如你需要一个业务 key 来查找 Broker 上的消息，方便在开发过程中诊断问题。
Tag
标签可以被认为是对 Topic 进一步细化。一般在相同业务模块中通过引入标签来标记不同用途的消息。
Broker
Broker是RocketMQ的核心模块，负责接收并存储消息，同时提供Push/Pull接口来将消息发送给Consumer。Consumer可选择从Master或者Slave读取数据。多个主/从组成Broker集群，集群内的Master节点之间不做数据交互。Broker同时提供消息查询的功能，可以通过MessageID和MessageKey来查询消息。Borker会将自己的Topic配置信息实时同步到NameServer。
Queue
Topic和Queue是1对多的关系，一个Topic下可以包含多个Queue，主要用于负载均衡。发送消息时，用户只指定Topic，Producer会根据Topic的路由信息选择具体发到哪个Queue上。Consumer订阅消息时，会根据负载均衡策略决定订阅哪些Queue的消息。
Offset
RocketMQ在存储消息时会为每个Topic下的每个Queue生成一个消息的索引文件，每个Queue都对应一个Offset记录当前Queue中消息条数。
NameServer
NameServer可以看作是RocketMQ的注册中心，它管理两部分数据：集群的Topic-Queue的路由配置；Broker的实时配置信息。其它模块通过Nameserv提供的接口获取最新的Topic配置和路由信息。
● Producer/Consumer ：通过查询接口获取Topic对应的Broker的地址信息
● Broker ： 注册配置信息到NameServer， 实时更新Topic信息到NameServer

rocketmq的工作流程

RocketMQ 是一个分布式消息中间件系统，其工作流程可以简单描述如下：

1. Producer 发送消息：
   生产者（Producer）通过发送消息到指定的 Topic（主题）。消息可以包含任意类型的数据，通常以键值对的形式发送。
2. Broker 存储消息：
   接收到消息的 Broker 节点将消息存储到对应的队列中。消息在 Broker 中以顺序存储，每个 Topic 可以有多个队列，用于水平扩展和提高并发处理能力。
3. Consumer 消费消息：
   消费者（Consumer）订阅感兴趣的 Topic，并从 Broker 获取消息进行消费。消费者可以以不同的消费模式（如广播模式、集群模式）消费消息。
4. 消息过滤和路由：
   RocketMQ 支持根据 Tag 进行消息过滤，消费者可以根据 Tag 过滤出需要的消息。此外，RocketMQ 还支持消息路由，确保相同 Key 的消息被发送到同一个队列，保证消息的有序性。
5. 消息顺序保证：
   RocketMQ 提供有序消息功能，确保消息按照发送顺序被消费。通过设置 MessageQueueSelector 接口实现消息的有序发送和消费。
6. 高可用性和容错：
   RocketMQ 集群部署方式支持主备架构，可以保证消息队列的高可用性和容错性。当 Master 节点宕机时，会自动选举一个 Slave 节点作为新的 Master，保证服务的持续性。
7. 监控和管理：
   RocketMQ 提供了丰富的监控和管理工具，可以实时监控消息发送和消费情况，查看集群健康状态，帮助用户及时发现和解决问题。
   总的来说，RocketMQ 的工作流程包括消息生产、存储、消费、过滤、路由、顺序保证等环节，通过这些环节协同工作，实现了高性能、可靠性的消息传递和处理机制。

Broker 高可用集群

Broker 通过主从集群来实现消息高可用。跟 Kafka 不同的是，RocketMQ 并没有 Master 节点选举功能，而是采用多 Master 多 Slave 的集群架构。Producer 写入消息时写入 Master 节点，Slave 节点主动从 Master 节点拉取数据来保持跟 Master 节点的数据一致。
Consumer 消费消息时，既可以从 Master 节点拉取数据，也可以从 Slave 节点拉取数据。 到底是从 Master 拉取还是从 Slave 拉取取决于 Master 节点的负载和 Slave 的同步情况 。如果 Master 负载很高，Master 会通知 Consumer 从 Slave 拉取消息，而如果 Slave 同步消息进度延后，则 Master 会通知 Consumer 从 Master 拉取数据。总之，从 Master 拉取还是从 Slave 拉取由 Master 来决定。
如果 Master 节点发生故障，RocketMQ 会使用基于 raft 协议的 DLedger 算法来进行主从切换。Broker 每隔 30s 向 Name Server 发送心跳，Name Server 如果 120s 没有收到心跳，就会判断 Broker 宕机了

刷盘策略

RocketMQ 采用灵活的刷盘策略。
异步刷盘
消息写入 CommitLog 时，并不会直接写入磁盘，而是先写入PageCache 缓存中，然后用后台线程异步把消息刷入磁盘。异步刷盘策略就是消息写入 PageCache 后立即返回成功，这样写入效率非常高。如果能容忍消息丢失，异步刷盘是最好的选择。
同步刷盘
即使同步刷盘，RocketMQ 也不是每条消息都要刷盘，线程将消息写入内存后，会请求刷盘线程进行刷盘，但是刷盘线程并不会只把当前请求的消息刷盘，而是会把待刷盘的消息一同刷盘。同步刷盘策略保证了消息的可靠性，但是也降低了吞吐量，增加了延迟。