RocketMQ生产01：生产部署方案 - 集群规划与容量评估

引言：生产环境的挑战

开发环境跑得欢，生产一上就翻车？RocketMQ 的生产部署是个系统工程，涉及集群规划、容量评估、高可用设计等多个维度。本文将从第一性原理出发，带你构建一个稳定可靠的生产集群。

为什么需要认真规划？

血泪教训：

❌ 磁盘空间不足，消息写入失败，业务中断
❌ 单点故障，Broker 宕机，服务不可用
❌ 容量估算错误，高峰期消息堆积，处理延迟
❌ 网络带宽不足，吞吐量上不去，性能瓶颈

核心目标：

✅ 高可用：任意节点故障不影响服务
✅ 高性能：满足业务峰值吞吐量需求
✅ 可扩展：支持业务增长，弹性伸缩
✅ 易运维：监控完善，故障快速定位

一、部署架构模式

1.1 单 Master 模式

架构图：

┌─────────────┐
│  Producer   │
└─────┬───────┘
      │
┌─────▼───────┐      ┌─────────────┐
│ NameServer  │◄─────┤  Consumer   │
└─────┬───────┘      └─────────────┘
      │
┌─────▼───────┐
│   Broker    │
│  (Master)   │
└─────────────┘

特点：

✅ 部署简单，成本低
❌ 单点故障风险
❌ 不支持高可用

适用场景：

开发测试环境
低重要性业务
POC 验证

配置示例：

# broker.conf
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=0
deleteWhen=04
fileReservedTime=48
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH

# 存储路径
storePathRootDir=/data/rocketmq/store
storePathCommitLog=/data/rocketmq/store/commitlog

1.2 多 Master 模式（推荐生产）

架构图：

                ┌─────────────┐
                │ NameServer  │
                │  Cluster    │
                └──────┬──────┘
                       │
       ┌───────────────┼───────────────┐
       │               │               │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│   Broker-A  │ │   Broker-B  │ │   Broker-C  │
│  (Master)   │ │  (Master)   │ │  (Master)   │
└─────────────┘ └─────────────┘ └─────────────┘

特点：

✅ 无单点故障
✅ 高吞吐量（负载分散）
❌ Broker 宕机期间，未消费消息不可订阅
❌ 实时性受影响（需等待磁盘恢复）

适用场景：

对消息可靠性要求不高
可容忍短暂消息不可用
追求高吞吐量

配置示例：

# Broker-A 配置
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=0
brokerRole=ASYNC_MASTER

# Broker-B 配置
brokerClusterName=DefaultCluster
brokerName=broker-b
brokerId=0
brokerRole=ASYNC_MASTER

# Broker-C 配置
brokerClusterName=DefaultCluster
brokerName=broker-c
brokerId=0
brokerRole=ASYNC_MASTER

1.3 多 Master 多 Slave 模式（高可用推荐）

架构图：

                ┌─────────────┐
                │ NameServer  │
                │  Cluster    │
                └──────┬──────┘
                       │
       ┌───────────────┼───────────────┐
       │               │               │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│  Broker-A   │ │  Broker-B   │ │  Broker-C   │
│  (Master)   │ │  (Master)   │ │  (Master)   │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
       │               │               │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│  Broker-A   │ │  Broker-B   │ │  Broker-C   │
│  (Slave)    │ │  (Slave)    │ │  (Slave)    │
└─────────────┘ └─────────────┘ └─────────────┘

特点：

✅ 高可用保障
✅ Master 宕机，Slave 继续提供消费服务
✅ 支持同步/异步双写
✅ 实时性高

刷盘策略对比：

策略	Master写入	Slave同步	性能	可靠性	推荐场景
异步刷盘 + 异步复制	内存返回	异步	⭐⭐⭐⭐⭐	⭐⭐	低重要性消息
异步刷盘 + 同步复制	Slave确认	同步	⭐⭐⭐⭐	⭐⭐⭐⭐	常规业务（推荐）
同步刷盘 + 同步复制	磁盘+Slave	同步	⭐⭐⭐	⭐⭐⭐⭐⭐	金融级业务

配置示例（异步刷盘 + 同步复制）：

# Broker-A Master 配置
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=0
brokerRole=SYNC_MASTER          # 同步复制
flushDiskType=ASYNC_FLUSH       # 异步刷盘
listenPort=10911

# Broker-A Slave 配置
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=1                      # Slave ID > 0
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
listenPort=10921

1.4 Dledger 高可用模式（自动主从切换）

架构图：

┌─────────────────────────────────────────┐
│         RocketMQ Dledger Cluster        │
│                                         │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐
│  │ Broker-A │  │ Broker-B │  │ Broker-C │
│  │ (Leader) │  │(Follower)│  │(Follower)│
│  └────┬─────┘  └────┬─────┘  └────┬─────┘
│       └─────────────┼─────────────┘      │
│              Raft 协议选主               │
└─────────────────────────────────────────┘

特点：

✅ 基于 Raft 协议自动选主
✅ Master 故障自动切换
✅ 无需手动运维
⚠️ 至少需要 3 个节点（满足多数派）

适用场景：

对可用性要求极高
希望自动故障转移
运维团队技术能力强

配置示例：

# 启用 Dledger
enableDLegerCommitLog=true
dLegerGroup=broker-a
dLegerPeers=n0-127.0.0.1:40911;n1-127.0.0.1:40912;n2-127.0.0.1:40913
dLegerSelfId=n0

# 存储路径
storePathRootDir=/data/rocketmq/dledger/store

二、容量评估方法

2.1 评估维度

容量评估 = 业务量评估 + 资源评估 + 冗余系数

核心指标：

TPS（每秒事务数）：消息发送速率
消息大小：平均每条消息的字节数
消息保留时长：磁盘需保留多久的消息
峰值倍数：日常流量的峰值倍数
副本系数：Master-Slave 复制倍数

2.2 磁盘容量评估

公式：

磁盘容量 = 日均TPS × 消息大小 × 保留时长(秒) × 峰值倍数 × 副本系数 × 1.2（冗余）

案例 1：中小型业务

业务指标：

日均 TPS：1000 条/秒
消息大小：1KB
保留时长：3 天（259200 秒）
峰值倍数：3 倍
副本系数：2（1 Master + 1 Slave）

计算：

磁盘 = 1000 × 1KB × 259200 × 3 × 2 × 1.2
     = 1000 × 259200 × 3 × 2 × 1.2 KB
     = 1,866,240,000 KB
     ≈ 1.78 TB

建议配置：2TB SSD（每台 Broker）

案例 2：大型电商业务

业务指标：

日均 TPS：10,000 条/秒
消息大小：2KB
保留时长：7 天（604800 秒）
峰值倍数：5 倍（大促场景）
副本系数：2

计算：

磁盘 = 10000 × 2KB × 604800 × 5 × 2 × 1.2
     = 144,115,200,000 KB
     ≈ 137.6 TB

建议配置：
- 每台 Broker：20TB（支持水平扩展，8台）
- 或单台：更大容量（成本更高）

2.3 内存容量评估

内存用途：

PageCache（核心）：操作系统缓存，加速读写
JVM 堆内存：Broker 运行时内存
Direct Memory：零拷贝使用的堆外内存

推荐配置：

# 小型集群（TPS < 5000）
机器内存：16GB
JVM堆内存：8GB
PageCache：6GB（剩余系统使用）

# 中型集群（TPS 5000-20000）
机器内存：32GB
JVM堆内存：16GB
PageCache：14GB

# 大型集群（TPS > 20000）
机器内存：64GB+
JVM堆内存：32GB
PageCache：28GB+

JVM 配置示例：

# runbroker.sh
JAVA_OPT="${JAVA_OPT} -server -Xms16g -Xmx16g -Xmn8g"
JAVA_OPT="${JAVA_OPT} -XX:+UseG1GC -XX:MaxGCPauseMillis=200"
JAVA_OPT="${JAVA_OPT} -XX:+UnlockExperimentalVMOptions"
JAVA_OPT="${JAVA_OPT} -XX:G1NewSizePercent=30"
JAVA_OPT="${JAVA_OPT} -XX:G1MaxNewSizePercent=40"

2.4 CPU 与网络评估

CPU 核心数：

小型：8 核
中型：16 核
大型：32 核+

网络带宽：

带宽需求 = TPS × 消息大小 × 8（bit换算） × 副本系数 × 2（收发双向）

案例（TPS 10000，消息 2KB）：
= 10000 × 2KB × 8 × 2 × 2
= 640 Mbps
≈ 建议万兆网卡（10 Gbps）

三、集群规划实战

3.1 小型业务（TPS < 5000）

推荐架构：2 Master + 2 Slave

NameServer：2 台（内存 4GB，双机房）

Broker 集群：
- Broker-A Master（机房1）：16GB 内存，2TB SSD，8核CPU
- Broker-A Slave（机房2）：16GB 内存，2TB SSD，8核CPU
- Broker-B Master（机房2）：16GB 内存，2TB SSD，8核CPU
- Broker-B Slave（机房1）：16GB 内存，2TB SSD，8核CPU

优势：

✅ 跨机房容灾
✅ 成本可控
✅ 满足中小业务需求

3.2 中型业务（TPS 5000-20000）

推荐架构：3 Master + 3 Slave（Dledger模式）

NameServer：3 台（内存 8GB，三机房）

Broker 集群（Dledger自动主从切换）：
- Group-A：3 个节点（32GB 内存，5TB SSD，16核CPU）
- Group-B：3 个节点（32GB 内存，5TB SSD，16核CPU）
- Group-C：3 个节点（32GB 内存，5TB SSD，16核CPU）

共 9 台 Broker

优势：

✅ 自动故障切换
✅ 高可用保障
✅ 支持业务增长

3.3 大型业务（TPS > 20000）

推荐架构：6 Master + 6 Slave（双机房）

NameServer：3 台（内存 16GB，三节点）

Broker 集群：
机房1：
- 3 组 Master-Slave（每台 64GB 内存，10TB SSD，32核CPU）

机房2：
- 3 组 Master-Slave（同上配置）

共 12 台 Broker

扩展策略：

水平扩容：增加 Broker 组
垂直扩容：升级硬件配置
Topic 拆分：按业务拆分 Topic

四、部署最佳实践

4.1 目录规划

# 推荐的目录结构
/opt/rocketmq/             # 安装目录
/data/rocketmq/
  ├── store/               # 数据存储（大容量磁盘）
  │   ├── commitlog/       # 消息主存储
  │   ├── consumequeue/    # 消费队列索引
  │   └── index/           # 消息索引
  ├── logs/                # 日志目录
  └── conf/                # 配置文件

4.2 磁盘选型

磁盘类型	性能	成本	推荐场景
HDD 机械硬盘	低	低	低频场景，长期归档
SATA SSD	中	中	中小型业务
NVMe SSD	高	高	高吞吐量业务
RAID 10	极高	极高	金融级业务

4.3 操作系统优化

# 1. 调整文件句柄限制
echo "* soft nofile 655350" >> /etc/security/limits.conf
echo "* hard nofile 655350" >> /etc/security/limits.conf

# 2. 关闭swap（避免内存交换）
swapoff -a
sed -i '/swap/s/^/#/' /etc/fstab

# 3. 调整内核参数
cat >> /etc/sysctl.conf <<EOF
# 最大文件句柄
fs.file-max = 2097152

# 网络优化
net.core.somaxconn = 2048
net.core.netdev_max_backlog = 2048
net.ipv4.tcp_max_syn_backlog = 2048

# 虚拟内存
vm.swappiness = 0
vm.max_map_count = 655360
EOF

sysctl -p

4.4 时钟同步

# 安装NTP
yum install -y ntp

# 配置时钟同步
systemctl enable ntpd
systemctl start ntpd

# 验证同步
ntpq -p

重要性：

RocketMQ 依赖时间戳排序
时钟偏差会导致消息乱序
建议使用统一的 NTP 服务器

五、扩容策略

5.1 水平扩容

场景：业务增长，现有集群接近容量上限

步骤：

# 1. 部署新 Broker
# 2. 配置相同的 brokerClusterName
# 3. 启动 Broker，自动注册到 NameServer
# 4. 新 Topic 自动分布到新 Broker
# 5. 现有 Topic 需手动迁移（或等待自然淘汰）

# 查看集群状态
sh mqadmin clusterList -n 127.0.0.1:9876

优势：

✅ 不影响现有服务
✅ 灵活调整容量
✅ 平滑扩展

5.2 缩容策略

步骤：

# 1. 停止向目标 Broker 发送新消息（修改路由策略）
# 2. 等待消息消费完成
# 3. 检查消费进度
sh mqadmin consumerProgress -g <消费组> -n 127.0.0.1:9876

# 4. 下线 Broker
sh mqadmin cleanExpiredCQ -n 127.0.0.1:9876 -b 192.168.1.100:10911

# 5. 关闭 Broker 进程
sh mqshutdown broker

六、常见问题

Q1：如何选择 Master-Slave 还是 Dledger？

Master-Slave：

成熟稳定，社区使用广泛
需手动主从切换
适合大部分场景

Dledger：

自动选主，无需人工介入
相对较新，部分场景有坑
适合高可用要求极高的场景

建议：一般业务选 Master-Slave，核心业务且运维能力强选 Dledger

Q2：磁盘满了怎么办？

应急方案：

# 1. 缩短消息保留时间（临时）
fileReservedTime=24  # 改为1天

# 2. 手动清理过期文件
sh mqadmin cleanExpiredCQ -n 127.0.0.1:9876

# 3. 扩容磁盘（长期方案）

Q3：如何评估集群健康度？

关键指标：

# 1. 消息堆积量
sh mqadmin consumerProgress -g <消费组> -n 127.0.0.1:9876

# 2. Broker 负载
top  # 查看CPU、内存
df -h  # 查看磁盘使用率

# 3. 网络带宽
iftop  # 查看实时流量

# 4. GC 情况
jstat -gcutil <pid> 1000 10

健康标准：

✅ 消息堆积 < 10万条
✅ CPU < 70%
✅ 内存 < 80%
✅ 磁盘 < 75%
✅ GC 频率 < 1次/分钟

七、总结

部署架构选择

场景	推荐架构	节点数
开发测试	单 Master	1 Broker + 1 NameServer
小型业务	2M-2S	4 Broker + 2 NameServer
中型业务	Dledger 3组	9 Broker + 3 NameServer
大型业务	6M-6S	12 Broker + 3 NameServer

容量评估口诀

磁盘 = TPS × 消息大小 × 保留时长 × 峰值倍数 × 副本 × 1.2
内存 = JVM堆（业务量的50%）+ PageCache（越多越好）
CPU = 8核起步，高并发16核+
网络 = 千兆够用，万兆更好

核心原则

预留冗余：容量评估 × 1.5倍，应对突发流量
跨机房部署：Master-Slave 分散不同机房
监控先行：上线前搭建完善的监控
灰度发布：新集群先接入低重要性业务
定期演练：故障切换、扩缩容流程定期演练

下一篇预告：《监控体系搭建 - Prometheus + Grafana 实战》，我们将详细讲解如何搭建 RocketMQ 的监控体系，实现故障秒级发现。

本文关键词：生产部署 集群规划 容量评估 高可用架构

引言：生产环境的挑战#

为什么需要认真规划？#

一、部署架构模式#

1.1 单 Master 模式#

1.2 多 Master 模式（推荐生产）#

1.3 多 Master 多 Slave 模式（高可用推荐）#

1.4 Dledger 高可用模式（自动主从切换）#

二、容量评估方法#

2.1 评估维度#

2.2 磁盘容量评估#

2.3 内存容量评估#

2.4 CPU 与网络评估#

三、集群规划实战#

3.1 小型业务（TPS < 5000）#

3.2 中型业务（TPS 5000-20000）#

3.3 大型业务（TPS > 20000）#

四、部署最佳实践#

4.1 目录规划#

4.2 磁盘选型#

4.3 操作系统优化#

4.4 时钟同步#

五、扩容策略#

5.1 水平扩容#

5.2 缩容策略#

六、常见问题#

Q1：如何选择 Master-Slave 还是 Dledger？#

Q2：磁盘满了怎么办？#

Q3：如何评估集群健康度？#

七、总结#

部署架构选择#

容量评估口诀#

核心原则#

引言：生产环境的挑战

为什么需要认真规划？

一、部署架构模式

1.1 单 Master 模式

1.2 多 Master 模式（推荐生产）

1.3 多 Master 多 Slave 模式（高可用推荐）

1.4 Dledger 高可用模式（自动主从切换）

二、容量评估方法

2.1 评估维度

2.2 磁盘容量评估

2.3 内存容量评估

2.4 CPU 与网络评估

三、集群规划实战

3.1 小型业务（TPS < 5000）

3.2 中型业务（TPS 5000-20000）

3.3 大型业务（TPS > 20000）

四、部署最佳实践

4.1 目录规划

4.2 磁盘选型

4.3 操作系统优化

4.4 时钟同步

五、扩容策略

5.1 水平扩容

5.2 缩容策略

六、常见问题

Q1：如何选择 Master-Slave 还是 Dledger？

Q2：磁盘满了怎么办？

Q3：如何评估集群健康度？

七、总结

部署架构选择

容量评估口诀

核心原则