react 网站开发,甘南网站建设,阿里云虚拟主机怎么建设网站,优化公司排名文章目录 概述RocketMQ架构rocketmq的工作流程Broker 高可用集群刷盘策略 概述
RocketMQ一个纯java、分布式、队列模型的开源消息中间件#xff0c;前身是MetaQ#xff0c;是阿里研发的一个队列模型的消息中间件#xff0c;后开源给apache基金会成为了apache的顶级开源项目… 文章目录 概述RocketMQ架构rocketmq的工作流程Broker 高可用集群刷盘策略 概述
RocketMQ一个纯java、分布式、队列模型的开源消息中间件前身是MetaQ是阿里研发的一个队列模型的消息中间件后开源给apache基金会成为了apache的顶级开源项目具有高性能、高可靠、高实时、分布式特点。 RocketMQ是阿里开源的分布式消息中间件跟其它中间件相比RocketMQ的特点是纯JAVA实现集群和HA实现相对简单在发生宕机和其它故障时消息丢失率更低。
RocketMQ架构 ● Producer消息生产者 ● Consumer消费者 ● BrokerMQ 服务负责接收、分发消息 ● 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将消息发往指定的TopicConsumer订阅该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主要用于负载均衡。发送消息时用户只指定TopicProducer会根据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 也不是每条消息都要刷盘线程将消息写入内存后会请求刷盘线程进行刷盘但是刷盘线程并不会只把当前请求的消息刷盘而是会把待刷盘的消息一同刷盘。同步刷盘策略保证了消息的可靠性但是也降低了吞吐量增加了延迟。
