Rocketmq 基础

https://www.bilibili.com/video/BV1DY41127Be/?p=23&spm_id_from=pageDriver&vd_source=f0af7e8672950f05b84e56e88f09f32c

 

在 RocketMQ 中，如果两个主 Broker 服务同一个 Topic，当其中一个 Broker 宕机后，消息分配和消费行为会受到以下因素的影响：

---

1. Topic 的消息分区分布

• 在 RocketMQ 中，每个 Topic 会被划分为多个 队列（Queue）。
• 队列是具体的物理存储单位，每个队列都属于一个 Broker。
• 如果两个主 Broker 服务同一个 Topic，这个 Topic 的队列会分布在这两个 Broker 上（例如 BrokerA 和 BrokerB）。

---

2. 宕机时的消息分配情况

假设 Topic 有 8 个队列，分布如下：

• BrokerA：Queue 0、Queue 1、Queue 2、Queue 3
• BrokerB：Queue 4、Queue 5、Queue 6、Queue 7

如果 BrokerB 宕机后：

1. 生产者消息发送：

   • RocketMQ 的生产者通过 NameServer 获取 Topic 的路由信息。
   • 宕机后，NameServer 检测到 BrokerB 不可用，会从路由表中移除 BrokerB 的队列信息。
   • 生产者仅会将消息发送到 BrokerA 的队列（Queue 0-3）。
   • 由于路由动态更新，生产者在发送消息时会自动避开不可用的 Broker。

2. 消费者消息消费：

   • 消费者在消费消息时，也依赖于 NameServer 提供的路由信息。
   • 当 BrokerB 宕机后，消费者只能消费 BrokerA 上的队列（Queue 0-3）。
   • BrokerB 上的队列（Queue 4-7）暂时不可消费，直到 BrokerB 恢复。

---

3. 宕机后的消息处理与恢复

• 消息丢失：

  • 如果使用了 异步刷盘 或者 Broker 没有同步从节点，BrokerB 上未刷盘或未同步的消息可能会丢失。
  • 若使用了同步刷盘或者 Broker 有 Slave 副本，数据会更安全。

• 恢复后：

  • 当 BrokerB 恢复正常运行后，生产者和消费者会重新获取完整的路由信息。
  • BrokerB 的队列（Queue 4-7）会重新可用，生产者和消费者会再次均衡分布。

---

4. 如何提升高可用性

为了减小单点宕机的影响，可以采取以下措施：

1. 配置主从架构：

   • 给每个主 Broker 配置从节点（Slave），在主节点宕机时，从节点可以提供服务。
   • 推荐使用 SYNC_MASTER 模式，确保数据一致性。

2. 队列数量分配策略：

   • 在 Topic 配置中，合理分配队列数量，避免过度依赖某个 Broker。
   • 例如为每个 Broker 分配更多队列，增强均衡性。

3. 生产者重试机制：

   • 配置生产者的 消息发送重试策略，确保在一个 Broker 宕机时，能够重试发送到其他可用的 Broker。

4. 消费者负载均衡：

   • 消费者会动态更新路由表并调整负载，避免访问宕机的 Broker。

---

通过以上机制，RocketMQ 能够在 Broker 宕机后保持服务的稳定性，但需要注意的是，真正的高可用性仍依赖主从架构的配置和数据同步策略。