Rocketmq

信徒_123

已于 2025-04-07 01:47:33 修改

阅读量2.1k

点赞数 23

文章标签： rocketmq

于 2024-10-07 01:07:04 首次发布

本文链接：https://blog.youkuaiyun.com/qq_41893505/article/details/142698513

版权

简介

在这里插入图片描述
RocketMQ 的整体工作原理围绕着生产者、消费者、Broker 和 NameServer 四个核心组件展开。其消息的发送、存储、消费，以及路由发现的过程，形成了完整的工作流。

Producer 生产消息

生产者通过指定的 Topic 向 Broker 发送消息。生产者可以选择同步、异步或单向的方式发送消息。
在发送消息之前，Producer 会从 NameServer 获取与目标 Topic 相关的 Broker 路由信息，包括可以发送消息的 Broker 地址和相应的队列信息。
根据负载均衡算法，Producer 会选择一个 Broker，并将消息发送到该 Broker 上的一个消息队列中。
生产者发送消息后，Broker 会接收消息并进行持久化。消息持久化到磁盘（CommitLog）后，Broker 返回一个确认给生产者，以确保消息已成功存储。

Broker 存储消息

Broker 将接收到的消息存储在 CommitLog 中。CommitLog 是按顺序写入磁盘的，保证了高效的写入性能。
Broker 会为每个 Topic 维护一个或多个 消息队列（Message Queue），每个消息队列中保存的是指向 CommitLog 的消息索引。
消费者从这些消息队列中读取消息，而不是直接访问 CommitLog。
如果 Broker 处于 主从架构中，消息会从 Master Broker 复制到 Slave Broker。这是为了保证高可用性和数据冗余，当 Master Broker 故障时，Slave Broker 可以顶上继续服务。

NameServer 管理路由信息

NameServer 是一个轻量级的服务，负责管理 Broker 的注册与路由信息。每个 Broker 在启动时都会将自身的信息（例如：IP 地址、端口、所在的 Topic 等）注册到 NameServer。
生产者和消费者在发送或消费消息时，都需要先从 NameServer 获取到 Broker 的路由信息。
NameServer 是无状态的，因此可以部署多个实例提高可用性。它的主要功能就是维护 Broker 的路由表，并为客户端（Producer 和 Consumer）提供查询服务。

Consumer 消费消息

RocketMQ 通过多种机制确保消息的可靠性，主要体现在消息的持久化、确认、重试、事务管理等方面。

消息持久化

CommitLog：RocketMQ 使用 CommitLog 将消息持久化到磁盘。这是一个顺序写入的日志文件，保证了高效的消息写入性能。通过持久化，系统即使在意外故障后也能恢复消息数据。
消息复制：在 Master-Slave 架构中，RocketMQ 会将消息从 Master Broker 复制到 Slave Broker。这提供了数据冗余，确保在 Master Broker 故障时，Slave Broker 可以继续提供服务，保证消息不会丢失。

消息确认机制

生产者确认：生产者在发送消息时，可以选择不同的确认模式：
- 同步确认：生产者在发送消息后，等待 Broker 确认消息已被持久化后再继续发送。这样可以确保消息确实被成功接收和存储。
- 异步确认：生产者发送消息后不等待 Broker 确认，适用于对延迟要求较高的场景，但在失败情况下，可能会丢失消息。
- 单向发送：适用于不需要确认的场景，速度快但不保证消息的可靠性。
消费者确认：消费者在成功处理消息后，需要向 Broker 发送确认，标记消息为已消费。未确认的消息将会在消费者出现异常时重投递。

消息重试机制

重试策略：如果消费者在处理消息时发生错误，RocketMQ 支持重试机制。消费者可以重新消费未确认的消息，直到达到最大重试次数为止，确保消息能够被成功处理。
死信队列：当消息在消费时多次重试仍然失败，RocketMQ 可以将这些消息转发到一个专门的死信队列（Dead Letter Queue），以便后续分析和处理。

事务消息
RocketMQ 支持事务消息，可以确保分布式系统中多个操作的一致性。在发送事务消息时，生产者会先发送一个“半消息”，然后在执行相关业务逻辑后提交或回滚该消息。只有在业务成功完成的情况下，消息才会被提交并持久化。

顺序消息
RocketMQ 支持顺序消息的发送和消费，确保消息按照发送顺序被处理。在某些业务场景中，顺序性对于数据的一致性和可靠性至关重要。

高可用性架构

Master-Slave 结构：通过设置 Master 和 Slave，RocketMQ 提供了高可用性。如果 Master Broker 故障，消费者可以从 Slave Broker 中拉取消息，保证消息不会丢失。
多副本机制：在集群环境中，消息可以在多个 Broker （一主多从）之间进行备份，提高系统的可靠性。

消息队列

消息队列的设计：在 RocketMQ 中，每个 Topic 可以有多个消息队列（Message Queue）。为了保证消息的有序性，通常会为一个 Topic 设置多个队列，但确保同一条消息的生产和消费只在同一个队列中进行。
队列选择：在发送消息时，生产者根据一定的逻辑（如 hash 算法）将消息发送到特定的消息队列中。这意味着对于相同的消息键