RocketMQ的一些原理

RocketMQ的一些原理_第1张图片

1.组成

Apache RocketMQ 由多个组件组成,这些组件协同工作以提供分布式消息传递服务。以下是 RocketMQ 的主要组成部分:

  • NameServer: NameServer 是 RocketMQ 集群的管理组件之一。它主要负责存储 Broker 的路由信息和元数据。生产者和消费者通过访问 NameServer 来获取当前可用的 Broker 地址、主题的路由信息等。NameServer 支持水平扩展,多个 NameServer 可以组成一个集群,以提高可用性和容错性。

  • Broker: Broker 是 RocketMQ 的核心组件,负责存储消息和处理消息的发送和接收。每个 Broker 实例都存储一部分主题的消息,这些消息按照消息队列的方式组织。Broker 负责管理消息的存储、检索和传递。RocketMQ 集群可以包含多个 Broker,它们通过 NameServer 进行协调。

  • Producer: 生产者是消息的发送方,负责将消息发布到指定的主题。生产者将消息发送到 Broker,然后由 Broker 存储和传递消息。生产者通常通过网络与 NameServer 交互,获取当前可用的 Broker 地址。

  • Consumer 消费者是消息的接收方,负责订阅主题并消费消息。消费者通过与 NameServer 交互,获取主题的路由信息,然后从相应的 Broker 上拉取消息。RocketMQ 支持两种消费模式:拉模式和推模式。

  • Message: 消息是 RocketMQ 传递的基本单元。它包含消息内容、主题、标签、键(Key)等信息。消息被生产者发送到主题,然后由消费者订阅和消费。消息在 Broker 中以消息队列的形式存储,由消费者按顺序拉取。

  • Message Queue: 每个主题被分为多个消息队列,每个消息队列在一个 Broker 上。消息队列是 RocketMQ 中的基本存储和传递单位,它保证了消息的有序性和分布式处理的能力。

  • Filter Server: Filter Server 是用于支持 SQL92 表达式过滤消息的组件。通过配置过滤表达式,消费者可以只接收满足条件的消息。Filter Server 在消费者端执行消息过滤,确保只有符合条件的消息被消费。

  • Transaction Producer: 事务生产者是支持分布式事务消息的生产者。它允许应用程序在发送消息时执行本地事务,根据事务结果决定是否提交或回滚消息。RocketMQ 通过协调器(Coordinator)和 CheckListener 机制来保证事务消息的最终一致性。

  • Coordinator(协调器): Coordinator 是用于支持分布式事务消息的组件。在事务消息的发送端,Producer 将协调器与本地事务相关联。在本地事务执行完毕后,协调器将收到的事务消息标记为"已提交"或"已回滚",以保证消息的最终一致性。

  • CheckListener(检查监听器): CheckListener 是用于支持分布式事务消息的组件。在事务消息的接收端,Consumer 向协调器注册 CheckListener。当协调器发起事务消息的状态检查时,CheckListener 负责向协调器报告本地事务的执行结果,以确保事务消息得到正确的提交或回滚。

  • Client: 客户端是指 RocketMQ 的使用者,既包括生产者也包括消费者。生产者通过客户端将消息发送到 RocketMQ 集群,而消费者通过客户端从 RocketMQ 集群中拉取消息。

  • Store(存储引擎): 存储引擎负责实际的消息存储。RocketMQ 支持多种存储引擎,例如内存存储、本地文件存储和支持分布式存储系统的存储引擎。存储引擎负责消息的写入和检索,确保消息在 Broker 中被可靠地存储和传递。

  • Remoting: Remoting 是 RocketMQ 中的远程通信模块,用于处理消息在不同节点之间的传递。它提供了基于 TCP 和 Netty 的通信机制,确保了消息在生产者、消费者、Broker 之间的高效传输。

  • Filter Server: Filter Server 是用于支持 SQL92 表达式过滤消息的组件。通过配置过滤表达式,消费者可以只接收满足条件的消息。Filter Server 在消费者端执行消息过滤,确保只有符合条件的消息被消费。

  • Transaction Check Listener: 在支持分布式事务的场景中,Transaction Check Listener 是用于监听事务状态检查的组件。它负责处理事务消息的状态检查请求,与 Coordinator 和 CheckListener 协同工作,以保证事务消息的最终一致性。

这些组件共同构成了一个完整的 RocketMQ 集群,提供了可靠的、低延迟的消息传递服务。通过这些组件的协同工作,RocketMQ 能够处理高吞吐、大规模的消息流,并支持多个应用程序或服务之间的消息通信。

2.消息分发消费过程

RocketMQ 的消息分发和消费过程如下:

  • 消息生产: 生产者将消息发送到指定的主题(Topic)。消息可以包含文本、二进制数据等内容。

  • 主题和消息队列: 主题是消息的逻辑分类,消息被分发到主题下的不同消息队列(Message Queue)。每个主题可以包含多个消息队列,每个消息队列在一个 Broker 上。

  • 消息存储: 消息被存储在 Broker 的存储引擎中。存储引擎负责消息的写入、检索和传递。

  • 消息分发: 消息队列中的消息会按照一定的分发策略分发给消费者。RocketMQ 支持多种消息分发策略,包括轮询、随机、哈希等。不同的分发策略适用于不同的业务场景。

  • 消费者订阅主题: 消费者订阅感兴趣的主题。消费者通过与 NameServer 交互,获取主题的路由信息,包括该主题有哪些消息队列以及它们在哪个 Broker 上。

  • 消息拉取: 消费者从分配给它的消息队列拉取消息。RocketMQ 支持两种消费模式:拉模式和推模式。在拉模式下,消费者主动从 Broker 拉取消息,而在推模式下,消息会被推送给消费者。

  • 消息过滤(可选): 消费者可以配置消息过滤器,只消费满足特定条件的消息。这通过在消息消费端使用 Filter Server 实现,确保只有符合条件的消息被消费。

  • 消息消费: 消费者消费拉取到的消息。消费者将消息传递给业务逻辑处理程序,处理程序执行相应的业务逻辑,例如更新数据库、触发事件等。

  • 消息确认: 消费者在成功处理消息后,向 RocketMQ 确认消息的消费状态。确认消息的消费状态有两种:ACK(表示成功消费)和 NACK(表示消费失败,需要重新消费)。

  • 消息状态检查(可选): 在支持分布式事务的场景中,RocketMQ 可能会定期检查事务消息的状态。这通过协调器(Coordinator)和 CheckListener 机制来实现,以确保事务消息的最终一致性。

  • 消息存储删除: 根据消费者的确认状态,RocketMQ 可能会删除已经被成功消费的消息,或者保留未被成功消费的消息以备后续重新消费。

这个整体过程保证了消息在生产者和消费者之间的可靠传递和处理。RocketMQ 的设计注重高性能、可靠性和灵活性,使其适用于各种分布式消息传递场景。

3.功能特性

  • 分布式架构: RocketMQ 采用分布式架构,支持横向扩展,可以方便地根据业务需求扩展集群规模,提高消息处理能力。

  • 高性能: RocketMQ 通过优化消息存储引擎和消息传递机制,实现了低延迟、高吞吐量的消息传递。它适用于对消息处理性能有较高要求的场景,如实时日志处理、实时数据分析等。

  • 消息顺序保证: RocketMQ 提供了消息队列级别的有序消息传递机制,确保消息在发送和接收时的顺序一致性。这对于某些业务场景,如订单支付、事务处理等至关重要。

  • 灵活的消息过滤机制: RocketMQ 支持通过 SQL 表达式配置消息过滤器,消费者可以根据业务需求只消费感兴趣的消息,以提高消息订阅的灵活性。

  • 分布式事务消息: RocketMQ 提供分布式事务消息的支持,允许在消息发送时执行本地事务。协调器(Coordinator)和 CheckListener 机制确保了事务消息的最终一致性。

  • 高可用性: RocketMQ 通过支持多个 NameServer、多个 Broker、主从复制等机制,提供了高可用性的消息传递服务。当某个节点出现故障时,系统可以自动进行切换。

  • 水平扩展: RocketMQ 支持通过添加更多的 Broker 节点和扩展集群规模,以满足大规模消息传递的需求。这种水平扩展性使得 RocketMQ 适用于不断增长的业务负载。

  • 实时消息处理: RocketMQ 提供实时的消息传递和处理能力,支持快速的消息发布、订阅和消费。这使得 RocketMQ 在实时监控、日志处理、实时数据分析等场景中得到广泛应用。

  • 丰富的监控和管理工具: RocketMQ 提供了多种监控和管理工具,包括控制台、监控报警等,帮助用户更好地了解和管理消息中间件的运行状态。

4.消息存储

Apache RocketMQ 使用存储时长作为消息存储的依据,即每个节点对外承诺消息的存储时长。在存储时长范围内的消息都会被保留,无论消息是否被消费;超过时长限制的消息则会被清理掉。

消息存储机制主要定义以下关键问题:

  • 消息存储管理粒度:Apache RocketMQ 按存储节点管理消息的存储时长,并不是按照主题或队列粒度来管理。

  • 消息存储判断依据:消息存储按照存储时间作为判断依据,相对于消息数量、消息大小等条件,使用存储时间作为判断依据,更利于业务方对消息数据的价值进行评估。

  • 消息存储和是否消费状态无关:Apache RocketMQ 的消息存储是按照消息的生产时间计算,和消息是否被消费无关。按照统一的计算策略可以有效地简化存储机制。

消息在队列中的存储情况如下:

RocketMQ的一些原理_第2张图片

  •  Apache RocketMQ 消息默认存储在本地磁盘文件中,存储文件的根目录由配置参数 storePathRootDir 决定,存储结构如下图所示,其中 commitlog 文件夹存储消息物理文件,consumeCQueue文件夹存储逻辑队列索引,其他文件的详细作用可以参考代码解析。

RocketMQ的一些原理_第3张图片 

5.事务消息

RocketMQ的一些原理_第4张图片

RocketMQ 提供了分布式事务消息的支持,这允许在消息发送时执行本地事务,并根据事务结果决定是否提交或回滚消息。以下是 RocketMQ 事务消息的基本原理和流程:

  • 事务消息的发送: 事务消息的发送分为两个阶段。

    • 事务消息的预发送(Half Message): 生产者发送事务消息时,首先发送一条预发送消息,也称为 Half Message。Half Message 包含了消息内容以及事务的执行信息。
    • 执行本地事务: 消息发送成功后,生产者执行本地事务。本地事务可能会涉及数据库的操作、文件系统的写入等业务逻辑。
  • 本地事务执行结果通知: 生产者需要根据本地事务的执行结果通知 RocketMQ。

    • 如果本地事务执行成功,生产者发送提交事务消息的指令。
    • 如果本地事务执行失败,生产者发送回滚事务消息的指令。
  • Commit 或 Rollback 指令发送: 根据本地事务的执行结果,生产者向 RocketMQ 发送 Commit 或 Rollback 指令。

    • 如果发送 Commit 指令,表示本地事务执行成功,该事务消息将正式提交并进入消息队列,可以被消费者拉取和消费。
    • 如果发送 Rollback 指令,表示本地事务执行失败,该事务消息将被标记为回滚状态,不会被正式提交。
  • 事务消息状态检查: RocketMQ 周期性地执行事务消息状态检查。

    • 如果发现 Commit 或 Rollback 指令长时间未收到,RocketMQ 将询问生产者该事务消息的状态。
    • 如果生产者返回 Commit 指令,表示事务消息提交;如果返回 Rollback 指令,表示事务消息回滚。
  • CommitLog、Prepared消息和Half Message: 在消息的存储层面,RocketMQ 使用 CommitLog 存储事务消息的提交状态。Prepared 消息表示预发送的 Half Message,而 CommitLog 存储 Commit 或 Rollback 指令。

通过以上流程,RocketMQ 保证了事务消息在本地事务执行成功后才会被提交,而在本地事务执行失败后会被回滚。这种机制确保了事务消息的最终一致性,使得消息的发送和本地事务的执行在语义上是一致的。

更多内容见官网文档Why choose RocketMQ | RocketMQ

你可能感兴趣的:(系统设计,rocketmq)