RocketMQ 集群部署模式详解

最新推荐文章于 2025-09-25 11:16:17 发布

原创最新推荐文章于 2025-09-25 11:16:17 发布 · 746 阅读

28 ·

CC 4.0 BY-SA版权

文章标签：

#rocketmq #集群部署模式 #学习

MQ 专栏收录该内容

156 篇文章

订阅专栏

🚀 RocketMQ 集群部署模式详解

单 Master｜多 Master｜多 Master 多 Slave｜Dledger 模式

理解 Broker 角色（Master vs Slave）与高可用机制

在生产环境中，RocketMQ 的集群部署模式直接决定了系统的可用性、性能、数据一致性与容灾能力。
不同的部署模式适用于不同的业务场景。

本文将全面解析 RocketMQ 的五种核心部署模式，深入剖析其工作原理、优缺点、适用场景，并重点介绍当前最推荐的 Dledger 模式。

一、Broker 角色：Master vs Slave

在 RocketMQ 中，Broker 节点分为两种角色：

角色	说明	是否可写	是否可读
Master	主节点，负责接收生产者消息，是数据写入的唯一入口	✅ 是	✅ 是
Slave	从节点，从 Master 同步数据，主要用于容灾和读取	❌ 否（默认）	✅ 是（可配置）

⚠️ 注意：一个 Broker Name 下可以有多个节点（1个 Master + 多个 Slave），构成一个高可用组。

二、1. 单 Master 模式（仅用于开发测试）

✅ 架构：

仅部署一个 Broker 节点，无从节点
不参与任何复制

+-------------+
|  Broker-A   | ← Master（唯一节点）
+-------------+

✅ 优点：

部署简单，资源占用少
适合本地开发、功能测试

❌ 缺点：

单点故障：Broker 宕机 → 服务中断
无数据备份：磁盘损坏 → 消息丢失
不可用于生产环境

🎯 适用场景：

本地开发
功能验证
单机测试

⚠️ 生产环境禁止使用！

三、2. 多 Master 模式（无 Slave，高性能）

✅ 架构：

部署多个 Master 节点，无 Slave
每个 Master 独立工作，互不复制

         +-------------+
         |  Broker-A   | ← Master
         +-------------+
                   ↑
                   | NameServer
         +-------------+
         |  Broker-B   | ← Master
         +-------------+

✅ 优点：

优势	说明
高性能	所有节点都可写，吞吐量高
无主从延迟	数据直接写入本地
部署简单	无需配置复制

❌ 缺点：

问题	说明
存在单点故障	某个 Master 宕机 → 其上的 Topic 无法写入
数据丢失风险	该 Master 上的消息可能丢失
需客户端重试	生产者需配置多个 Master 地址，自动重试

🎯 适用场景：

对性能要求极高
可容忍部分消息丢失
有完善的重试和补偿机制

⚠️ 仍存在可用性风险，生产环境慎用。

四、3. 多 Master 多 Slave 模式（异步复制）

✅ 架构：

每个 Master 配置一个或多个 Slave
Slave 通过异步方式从 Master 同步数据

         +-------------+       +-------------+
         |  Broker-A    |<----->|  Broker-C    |
         |   Master     |       |    Slave     |
         +-------------+       +-------------+
                   ↑
                   | NameServer
         +-------------+       +-------------+
         |  Broker-B    |<----->|  Broker-D    |
         |   Master     |       |    Slave     |
         +-------------+       +-------------+

🔧 配置示例（broker-a-master.conf）：

brokerName=broker-a
brokerId=0
brokerRole=ASYNC_MASTER
namesrvAddr=192.168.0.1:9876;192.168.0.2:9876

Slave 配置：

brokerName=broker-a
brokerId=1
brokerRole=SLAVE

✅ 优点：

优势	说明
高可用	Master 宕机后，可手动或自动切换到 Slave
数据不丢失	Slave 有完整副本
性能较好	异步复制，不影响 Master 写入性能

❌ 缺点：

问题	说明
数据短暂不一致	Master 宕机时，未同步的数据会丢失
无自动选主	原生不支持自动故障转移（需外部工具）

🎯 适用场景：

大多数生产环境
要求高可用但可容忍极小概率数据丢失

✅ 推荐用于传统主从架构。

五、4. 多 Master 多 Slave 模式（同步双写）

✅ 架构：

Master 在写入本地前，先同步写入 Slave
只有 Slave 确认后，才返回 ACK 给生产者

Producer → Master → 同步写入 Slave
   ↓
等待 Slave 确认
   ↓
写入本地 CommitLog → 返回 ACK

🔧 配置：

brokerRole=SYNC_MASTER

✅ 优点：

优势	说明
强数据一致性	Master 和 Slave 数据完全一致
高可靠性	几乎不丢消息
适合金融级场景	如支付、转账

❌ 缺点：

问题	说明
性能低	网络往返 + Slave 写入延迟，TPS 下降 30%~60%
依赖网络稳定性	网络抖动会导致 Master 阻塞
仍无自动选主	故障后需人工干预

🎯 适用场景：

金融交易系统
对账系统
任何不允许消息丢失的场景

⚠️ 性能代价高，仅关键业务使用。

六、5. Dledger 模式（推荐）—— 基于 Raft 协议的自动高可用

✅ 为什么需要 Dledger？

传统主从模式缺乏自动选主能力，无法实现真正的高可用。
Dledger 模式是 RocketMQ 4.5+ 推出的下一代高可用方案，基于 Raft 一致性协议，实现自动选主、强一致、高可用。

✅ 架构：

每个 Broker 组由 3 或 5 个节点组成
基于 Raft 协议选举 Leader（即 Master）
数据写入需多数节点确认
故障时自动重新选举

         +-------------+
         |  Node-1     | ← 可能是 Leader
         +-------------+
         +-------------+
         |  Node-2     | ← Follower
         +-------------+
         +-------------+
         |  Node-3     | ← Follower
         +-------------+
               ↑
               | Dledger Group（基于 Raft）
               |
         +------------------+
         |   NameServer     |
         +------------------+

✅ 核心优势：

特性	说明
自动选主	节点宕机后自动选举新 Leader
强一致性	多数节点确认写入才算成功
高可用	3 节点允许 1 个故障，5 节点允许 2 个
无需外部依赖	内置 Dledger，不依赖 ZooKeeper
数据不丢失	即使 Leader 宕机，数据仍在多数节点

🔧 配置方式（使用 `DLedgerCommitLog`）：

# 启用 DLedger 模式
enableDLegerCommitLog=true

# 所属组
dLegerGroup=raft_group_01

# 所有节点列表
dLegerPeers=n0-192.168.0.10:40911;n1-192.168.0.11:40911;n2-192.168.0.12:40911

# 本节点 ID
dLegerSelfId=n0

⚠️ 注意：Dledger 模式不兼容传统 brokerRole 配置。

🎯 适用场景：

所有生产环境（强烈推荐）
金融、电商、支付等高可用要求场景
容器化部署（Kubernetes）

✅ Dledger 是当前最推荐的部署模式。

七、五种部署模式对比总结

模式	是否高可用	数据一致性	性能	自动选主	推荐度
单 Master	❌ 否	❌ 无备份	⭐⭐⭐⭐⭐	❌ 无	❌ 禁止生产
多 Master	⚠️ 部分	⚠️ 有丢失风险	⭐⭐⭐⭐⭐	❌ 无	⚠️ 慎用
多 Master 多 Slave（异步）	✅ 是	⚠️ 短暂不一致	⭐⭐⭐⭐	❌ 无	✅ 推荐
多 Master 多 Slave（同步）	✅ 是	✅ 强一致	⭐⭐⭐	❌ 无	⚠️ 关键业务
Dledger 模式	✅ 是	✅ 强一致	⭐⭐⭐⭐	✅ 有	✅✅ 强烈推荐

八、最佳实践建议

实践	说明
✅ 生产环境使用 Dledger 模式	实现自动高可用
✅ 至少部署 3 个 Dledger 节点	支持 1 个故障
✅ 传统模式使用 ASYNC_MASTER + SLAVE	平衡性能与可用性
✅ 开启 `slaveReadEnable=true`	允许消费者从 Slave 读取
✅ 监控 Broker 状态和复制延迟	使用 `mqadmin brokerStatus`
✅ 避免单 Master 部署	无任何容灾能力
✅ 结合 NameServer 高可用	至少部署 2 个 NameServer

✅ 总结

部署模式	核心思想	一句话总结
单 Master	简单至上	“开发用用，生产别碰”
多 Master	性能优先	“都能写，但挂了就没了”
异步主从	高可用 + 性能	“主挂了，从顶上（手动）”
同步主从	安全至上	“主从都写完才算成功”
Dledger	自动高可用	“自动选主，永不宕机”