RocketMQ 运维实践：扩容与缩容

🚀 RocketMQ 运维实践：扩容与缩容

安全地增加/减少 Broker 节点或 Topic 队列数

在生产环境中，随着业务增长或资源优化需求，对 RocketMQ 集群进行扩容（Scale Out）或缩容（Scale In） 是常见的运维操作。
但不当的操作可能导致消息积压、消费中断、数据不一致等问题。

本文将系统化讲解如何安全、平滑地进行 Broker 节点和 Topic 队列的扩容与缩容，确保服务高可用、数据不丢失。

---

一、核心原则：安全第一

在进行任何变更前，必须遵守以下原则：

原则	说明
✅ 先扩容，后缩容	避免服务中断
✅ 逐个操作，避免批量变更	降低风险
✅ 监控先行	变更前后观察 TPS、延迟、GC 等指标
✅ 备份配置与数据	防止误操作
✅ 灰度验证	新节点先接入小流量验证

---

二、1. 扩容 Broker 节点（Scale Out）

✅ 场景：

• 消息吞吐量上升
• 磁盘空间不足
• 提升高可用性

🔄 扩容方式：

根据部署模式不同，扩容策略也不同。

---

（1）多 Master 模式（无 Slave）

✅ 扩容步骤：

1. 部署新 Broker 实例（broker-e）
   ↓
2. 配置 broker.conf：
   brokerClusterName=DefaultCluster
   brokerName=broker-e
   brokerId=0
   brokerRole=ASYNC_MASTER
   namesrvAddr=...
   ↓
3. 启动新 Broker
   ↓
4. NameServer 自动注册
   ↓
5. 生产者/消费者自动感知新节点（无需重启）

✅ 效果：新 Topic 可分布到新 Broker，提升整体容量。

---

（2）多 Master 多 Slave 模式

✅ 扩容主从组：

• 新增一组 Master + Slave
• 流程同上

✅ 为现有 Master 增加 Slave（提升容灾）：

1. 部署新 Slave 节点
   ↓
2. 配置：
   brokerName=broker-a  # 与 Master 相同
   brokerId=2           # 唯一 ID
   brokerRole=SLAVE
   ↓
3. 启动 Slave，自动从 Master 同步数据

---

（3）Dledger 模式（推荐）

✅ 扩容步骤：

1. 修改所有节点的 dLegerPeers 配置，加入新节点
   dLegerPeers=n0-192.168.0.10:40911;n1-192.168.0.11:40911;n2-192.168.0.12:40911;n3-192.168.0.13:40911
   ↓
2. 依次重启每个节点（滚动更新）
   ↓
3. 新节点自动加入 Raft 组，参与选主

✅ Dledger 支持动态扩缩容，无需停机。

---

三、2. 缩容 Broker 节点（Scale In）

⚠️ 风险：

• 若直接关闭 Broker，其上的 Topic 将无法读写
• 可能导致消息丢失或消费中断

✅ 安全缩容步骤：

1. 确认待缩容 Broker 上的 Topic 是否有数据
   ↓
2. 若有数据，需先迁移 Topic（见下文）
   ↓
3. 若无数据或已迁移：
   a. 停止该 Broker 进程
   b. 从 dLegerPeers 或集群配置中移除
   c. 更新客户端配置（可选）

✅ 建议：缩容前先扩容，确保服务能力不降。

---

四、3. 扩容 Topic 队列数（MessageQueue）

✅ 场景：

• 消费者处理慢，存在积压
• 需要提升并发消费能力

✅ 扩容方式：

（1）自动创建 Topic（不推荐生产使用）

• 修改 defaultTopicQueueNums → 新创建的 Topic 会使用新值

（2）手动扩容现有 Topic（推荐）

# 使用 mqadmin 扩容队列数
sh mqadmin updateTopic \
  -n 192.168.0.1:9876 \
  -c DefaultCluster \
  -t ORDER_TOPIC \
  -r 16 \  # 原为8，现扩容至16
  -w 16

✅ 扩容后，Producer 会自动将新消息分布到新增的 Queue。

---

✅ 对消费者的影响：

• 集群消费模式：Rebalance 触发，新增 Queue 被分配给消费者
• 顺序消息：新增 Queue 不影响已有 Sharding Key 的分布
• 无需重启消费者

---

五、4. 缩容 Topic 队列数（⚠️ 不支持直接缩容）

❌ 问题：

RocketMQ 不支持直接减少 MessageQueue 数量。
因为：

• 消息已按 Queue 分布，减少 Queue 会导致消息“无处可去”
• 可能导致数据丢失或消费混乱

✅ 替代方案：

方案一：新建 Topic（推荐）

1. 创建新 Topic（如 ORDER_TOPIC_V2，Queue=4）
   ↓
2. 生产者逐步切流到新 Topic
   ↓
3. 消费者订阅新 Topic 并验证
   ↓
4. 旧 Topic 消费完成后下线

✅ 适用于架构升级或队列过多场景。

方案二：保留但不再使用

• 保持原 Queue 数，但不再新增消息
• 让旧消息自然过期

---

六、5. 安全变更 Checklist

操作	检查项
扩容 Broker	✅ 配置正确、✅ 端口开放、✅ 磁盘充足、✅ 加入监控
缩容 Broker	✅ 无活跃 Topic、✅ 数据已迁移、✅ 已通知相关方
扩容 Queue	✅ 使用 mqadmin updateTopic、✅ 监控 Rebalance
变更生效	✅ 使用 mqadmin topicRoute -t TOPIC_NAME 验证
回滚准备	✅ 备份配置、✅ 准备回滚脚本

---

七、最佳实践建议

实践	说明
✅ 初始设置足够多的 Queue（8~16）	避免频繁扩容
✅ 使用 Dledger 模式	支持动态扩缩容
✅ 扩容前先压测	验证性能提升
✅ 缩容前确认无积压	使用 mqadmin consumerProgress 检查
✅ 变更在低峰期进行	如凌晨
✅ 结合配置中心管理 broker.conf	实现动态更新
✅ 监控 Broker 状态和磁盘使用率	及时发现瓶颈

---

八、常见问题与解决方案

问题	原因	解决方案
扩容后新节点无流量	Topic 未重新分布	等待路由更新或重启 Producer
消费者 Rebalance 频繁	网络抖动、GC 停顿	优化 JVM、提升网络稳定性
扩容 Queue 后消费变慢	消费者实例不足	扩容消费者
缩容失败	有活跃消息	先迁移或等待消费完成
Dledger 扩容失败	配置未同步	滚动重启所有节点

---

✅ 总结

操作	是否支持	推荐方式
扩容 Broker	✅ 支持	部署新节点，自动注册
缩容 Broker	⚠️ 可行但需谨慎	确保无数据后下线
扩容 Queue	✅ 支持	mqadmin updateTopic -r N
缩容 Queue	❌ 不支持	新建 Topic 迁移

🚀 一句话总结：
RocketMQ 支持安全的“加法”操作（扩容），但“减法”操作（缩容）需谨慎设计。
掌握这一原则，你就能在业务增长与资源优化之间，灵活调整消息系统规模。

建议：建立标准化的扩容/缩容流程，结合自动化脚本与监控告警，实现高效、安全的运维管理。