RocketMQ的一些原理

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 的消息存储是按照消息的生产时间计算，和消息是否被消费无关。按照统一的计算策略可以有效地简化存储机制。

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

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

 

5.事务消息

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