RocketMQ教程(五)：RocketMQ的工作原理2

工作原理

RocketMQ 是一个高性能、高吞吐量的分布式消息和流计算平台，它基于发布-订阅模式工作。其核心设计理念是确保消息传递的高效性、稳定性和可扩展性。RocketMQ 的工作原理主要可以分为以下几个部分：

 

1. 消息流程

• 消息发布: Producer 首先向 NameServer 查询目标 Topic 所在的 Broker 地址，然后将消息发送到这个 Broker。

• 消息存储: Broker 接收到消息后，将消息存储在磁盘或内存中。为了提高效率，Broker 会批量将消息存储到磁盘。

• 消息订阅: Consumer 启动时，向 NameServer 查询并订阅其感兴趣的 Topic，NameServer 返回对应的 Broker 地址。然后，Consumer 直接和 Broker 建立连接，进行消息拉取或等待 Broker 推送消息。

2. 高可用性设计

• 主从同步: 为了保证数据的可靠性和高可用性，Broker 可以配置为主从模式。在此模式下，主Broker负责处理读写请求，同时将数据同步到从Broker，以保证在主Broker宕机时，从Broker可以接管服务。

• 负载均衡: RocketMQ 支持集群模式，可以通过增加 Broker 实例来水平扩展系统的处理能力。同时，它在 Producer 和 Consumer 端都实现了负载均衡，确保消息的均匀分布和消费。

3. 消息确认和重试机制

• 消息确认: 消费者处理消息后，需要向Broker发送确认信息。如果Broker在规定时间内没有收到确认，它会重新投递该消息。

• 重试机制: 当消息消费失败时，RocketMQ 支持自动重试，增强了消息处理的可靠性。

RocketMQ 通过这些设计理念和工作原理，不仅保证了消息传输的高效与可靠，还可以根据业务需求灵活扩展，满足不同规模应用的需求。

消息消费

消费者从Broker中获取消息的方式分为两种：

• pull 拉取方式
• push 推送方式

消费者组对于消息消费的模式又分为两种：

• 集群消费Clustering
• 广播消费Broadcasting

拉取式消费:

Consumer主动从Broker中拉取消息，主动权由Consumer控制。一旦获取了批量消息，就会启动消费过程。不过，该方式的实时性较弱，即Broker中有了新的消息时消费者并不能及时发现并消费。由于拉取时间间隔是由用户指定的，所以在设置该间隔时需要注意平稳：间隔太短，空请求比例会增加；间隔太长，消息的实时性太差。

推送式消费:

该模式下Broker收到数据后会主动推送给Consumer。该获取方式一般实时性较高。 该获取方式是典型的发布-订阅模式，即Consumer向其关联的Queue注册了监听器，一旦发现有新的消息到来就会触发回调的执行，回调方法是Consumer去Queue中拉取消息。而这些都是基于Consumer与Broker间的长连接的。长连接的维护是需要消耗系统资源的。

拉取式和推送式的对比:

• pull：需要应用去实现对关联Queue的遍历，实时性差；但便于应用控制消息的拉取
• push：封装了对关联Queue的遍历，实时性强，但会占用较多的系统资源

广播消费

广播消费模式下，相同消费者组的每个消费者实例都接收同一个Topic的全量消息。即每条消息都会被发送到消费者组中的每个消费者。

集群消费

集群消费模式下，相同消费者组的每个消费者实例平均分摊同一个Topic的消息。即每条消息只会被发送到消费者组中的某个消费者，默认情况下是使用集群模式。

消费进度

广播模式：消费进度保存在 consumer 端。因为广播模式下consumer group中每个consumer都会消费所有消息，但它们的消费进度是不同。所以consumer各自保存各自的消费进度。

集群模式：消费进度保存在 broker 中。consumer group中的所有consumer共同消费同一个Topic中的消息，同一条消息只会被消费一次。消费进度会参与到了消费的负载均衡中，故消费进度是需要共享的。

集群消费进度保存在 "用户目录\store\config\consumerOffset.json" 路径下：