文章目录
- 概述
- RocketMQ架构
- rocketmq的工作流程
- Broker 高可用集群
- 刷盘策略
概述
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 是一个分布式消息中间件系统，其工作流程可以简单描述如下：
- Producer 发送消息：
生产者（Producer）通过发送消息到指定的 Topic（主题）。消息可以包含任意类型的数据，通常以键值对的形式发送。 - Broker 存储消息：
接收到消息的 Broker 节点将消息存储到对应的队列中。消息在 Broker 中以顺序存储，每个 Topic 可以有多个队列，用于水平扩展和提高并发处理能力。 - Consumer 消费消息：
消费者（Consumer）订阅感兴趣的 Topic，并从 Broker 获取消息进行消费。消费者可以以不同的消费模式（如广播模式、集群模式）消费消息。 - 消息过滤和路由：
RocketMQ 支持根据 Tag 进行消息过滤，消费者可以根据 Tag 过滤出需要的消息。此外，RocketMQ 还支持消息路由，确保相同 Key 的消息被发送到同一个队列，保证消息的有序性。 - 消息顺序保证：
RocketMQ 提供有序消息功能，确保消息按照发送顺序被消费。通过设置 MessageQueueSelector 接口实现消息的有序发送和消费。 - 高可用性和容错：
RocketMQ 集群部署方式支持主备架构，可以保证消息队列的高可用性和容错性。当 Master 节点宕机时，会自动选举一个 Slave 节点作为新的 Master，保证服务的持续性。 - 监控和管理：
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 也不是每条消息都要刷盘，线程将消息写入内存后，会请求刷盘线程进行刷盘，但是刷盘线程并不会只把当前请求的消息刷盘，而是会把待刷盘的消息一同刷盘。同步刷盘策略保证了消息的可靠性，但是也降低了吞吐量，增加了延迟。
