十三、集群部署与高可用
单机部署（开发/测试环境）
我们先从最简单的开始——单机部署。虽然生产环境不会用单机，但它是你快速上手、验证功能的最佳方式。

环境准备：

项 要求
操作系统 Linux（CentOS 7+ / Ubuntu 16+），开发环境也可用 Windows/Mac
JDK 1.8+，推荐 1.8
内存 开发环境最低 2C4G
磁盘 50GB+
部署步骤：

1. 下载并解压

wget https://archive.apache.org/dist/rocketmq/5.0.0/rocketmq-all-5.0.0-bin-release.zip
unzip rocketmq-all-5.0.0-bin-release.zip
cd rocketmq-all-5.0.0-bin-release

2. 启动 NameServer（默认端口 9876）

nohup sh bin/mqnamesrv &

3. 启动 Broker（连接到 NameServer）

nohup sh bin/mqbroker -n localhost:9876 &

4. 验证是否启动成功

sh bin/mqadmin clusterList -n localhost:9876
JVM 参数调整（bin/runserver.sh 和 bin/runbroker.sh）：

NameServer 轻量级，2GB 堆内存足够；Broker 建议根据机器配置调整：

runbroker.sh 中的 JVM 配置示例（8GB 堆内存）

JAVA_OPT=“${JAVA_OPT} -server -Xms8g -Xmx8g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m”
单机部署架构

发消息

拉消息

获取路由

获取路由

注册

NameServer
端口 9876

Producer

Broker
端口 10911

Consumer

⚠️ 仅适用于开发/测试环境
存在单点故障风险

💡 小贴士：NameServer 和 Broker 默认的 JVM 参数（-Xms4g -Xmx4g）在低配机器上可能启动失败，需要根据实际内存调小。

多 NameServer 部署
NameServer 是 RocketMQ 的“注册中心”，它的高可用直接决定了集群的可用性。

为什么 NameServer 要部署多个？

NameServer 的设计非常巧妙——节点之间完全无状态、不需要数据同步。所有的路由信息都是由 Broker 主动上报构建的。

这就意味着：你只要多启动几个 NameServer 实例，客户端配置上所有地址，任何一个 NameServer 挂掉都不影响服务。

部署方式：

在 3 台机器上分别启动 NameServer

机器 A: 192.168.1.10

nohup sh bin/mqnamesrv &

机器 B: 192.168.1.11

nohup sh bin/mqnamesrv &

机器 C: 192.168.1.12

nohup sh bin/mqnamesrv &
客户端配置：

// Producer 和 Consumer 配置多个 NameServer 地址
producer.setNamesrvAddr(“192.168.1.10:9876;192.168.1.11:9876;192.168.1.12:9876”);
Broker 集群

客户端

NameServer 集群 - 无状态

连接任意一个

连接任意一个

注册到所有

注册到所有

注册到所有

NameServer 1
192.168.1.10

NameServer 2
192.168.1.11

NameServer 3
192.168.1.12

Producer

Consumer

Broker Master A

✅ 任意一个 NameServer 宕机
其他节点仍可正常服务

NameServer 资源配置建议：

配置项 建议值
CPU 2 核（x86_64），主频 ≥ 2.4GHz
内存 4GB（实际使用约 500MB）
磁盘 50GB SSD（存储日志，日志轮转周期建议 7 天）
JVM 堆内存 2GB
Broker 主从集群部署（Master-Slave）
生产环境的标配是 多 Master 多 Slave 架构。

集群规划示例（双主双从）：

节点 角色 IP 端口
Broker-A-M Master 192.168.1.20 10911
Broker-A-S Slave 192.168.1.21 10911
Broker-B-M Master 192.168.1.22 10911
Broker-B-S Slave 192.168.1.23 10911
配置文件示例（broker-a-m.conf）：

集群名称

brokerClusterName = rocketmq-cluster

Broker 名称（主从配对使用相同名称）

brokerName = broker-a

Broker ID：0 表示 Master，>0 表示 Slave

brokerId = 0

NameServer 地址

namesrvAddr = 192.168.1.10:9876;192.168.1.11:9876;192.168.1.12:9876

存储路径

storePathRootDir = /data/rocketmq/store

消息保留时间（72 小时）

fileReservedTime = 72

刷盘策略：SYNC_FLUSH / ASYNC_FLUSH

flushDiskType = ASYNC_FLUSH

复制策略：SYNC_MASTER / ASYNC_MASTER

brokerRole = ASYNC_MASTER
Slave 配置（broker-a-s.conf）只需修改 brokerId = 1 和存储路径。

客户端

写入

写入

拉取

拉取

主从复制架构

Broker 组 B

Broker 组 A

同步/异步复制

同步/异步复制

Master B
brokerId=0
可读写

Master A
brokerId=0
可读写

Slave A
brokerId=1
只读

Slave B
brokerId=1
只读

Producer

Consumer

启动命令：

先启动所有 NameServer，再启动 Broker

nohup sh bin/mqbroker -c conf/broker-a-m.conf &
nohup sh bin/mqbroker -c conf/broker-a-s.conf &
nohup sh bin/mqbroker -c conf/broker-b-m.conf &
nohup sh bin/mqbroker -c conf/broker-b-s.conf &
Dledger 高可用集群部署与自动切换
传统主从架构有一个痛点：Master 宕机后需要人工切换。Dledger 解决了这个问题——基于 Raft 协议实现自动故障切换。

Dledger 的核心机制：

一个 Dledger Group 至少需要 3 个节点（遵循 2n+1 原则，容忍 1 个节点宕机）
通过 Raft 协议自动选举出一个 Leader，其余为 Follower
Leader 和 Follower 之间复制数据，保证高可用
RocketMQ 5.x 的 Dledger Controller 模式：

RocketMQ 5.0 引入了 Controller 组件来增强自动切换能力。Controller 可以独立部署，也可以嵌入 NameServer 部署。

Broker 副本组 - 三节点

Controller 集群 - 三副本

复制

复制

选主/心跳

选主/心跳

选主/心跳

Controller 1

Controller 2

Controller 3

Leader
处理读写

Follower 1
数据备份

Follower 2
数据备份

✅ Leader 宕机后
Controller 协调选举新 Leader
自动切换，无需人工干预

Controller 嵌入 NameServer 的配置：

namesrv.conf

enableControllerInNamesrv = true
controllerDLegerGroup = group1
controllerDLegerPeers = n0-127.0.0.1:9877;n1-127.0.0.1:9878;n2-127.0.0.1:9879
controllerDLegerSelfId = n0
controllerStorePath = /home/admin/DledgerController
enableElectUncleanMaster = false
Broker 开启 Controller 模式：

broker.conf

enableControllerMode = true
controllerAddr = 127.0.0.1:9877;127.0.0.1:9878;127.0.0.1:9879
💡 小贴士：Dledger Group 至少需要 3 个节点才能实现容灾切换。2 节点部署会丧失自动切换能力。

多机房多活部署方案
对于需要异地容灾或单元化架构的场景，多机房多活是必备能力。

方案一：单集群跨机房部署：

同一个 RocketMQ 集群的 Broker 分布在多个机房
每一对主从 Broker 分别部署在不同机房
尽量让两个机房的 Master 数量均衡（如 1:2 或 2:2）
客户端

机房 B

机房 A

同步复制

同步复制

就近写入

就近写入

Master A

Slave B

Master B

Slave A

Producer

✅ 单个机房故障
另一个机房的 Master 仍可提供服务
⚠️ 跨机房网络延迟是瓶颈

方案二：双集群异地双活：

两个独立的 RocketMQ 集群分别部署在两个机房
通过 Global Replicator 实现跨集群数据同步
平时业务写入各自机房的集群，一个机房故障时切换流量
支持双向同步，实现真正的“双活”
方案 优点 缺点 适用场景
单集群跨机房 部署简单，数据一致 跨机房延迟高 同城双机房
双集群双活 延迟低，可用性高 部署复杂，可能有数据冲突 异地容灾、单元化
NameServer 与 Broker 的资源配置建议
硬件配置核心原则：

垂直扩展优先：单节点性能不足时优先升级硬件，而非盲目增加节点
资源隔离：Broker、NameServer、监控组件部署在不同机器或容器中
弹性预留：生产环境预留 20%-30% 的硬件资源应对突发流量
各组件配置建议：

组件 场景 CPU 内存 磁盘
NameServer 通用 2 核 4GB（堆 2GB） 50GB SSD
Broker 普通消息 8 核 16GB（堆 8GB） NVMe SSD，IOPS≥50K
Broker 高吞吐（10 万+/s） 16 核 32GB（堆 12GB） RAID10 阵列（4 块 NVMe SSD）
Broker Slave 同步复制 12 核 16GB 不低于 Master
内存分配的关键原则：

堆内存占比不超过 60%（单节点堆内存 ≤ 32GB，避免 GC 停顿过长）
剩余内存用于 PageCache 加速磁盘 IO
启用 transientStorePoolEnable=true 和堆外内存池
JVM 参数调优与内存配置
NameServer JVM 参数：

JAVA_OPT=“${JAVA_OPT} -server -Xms2g -Xmx2g -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m”
Broker JVM 参数（16GB 内存机器）：

JAVA_OPT=“$JAV{A}_{O}PT-server-Xms8g-Xmx8g-XX:MetaspaceSize=256m-XX:MaxMetaspaceSize=512m"JAV{A}_{O}PT="${JAVA_OPT} -XX:+UseG1GC -XX:G1HeapRegionSize=16m -XX:G1ReservePercent=25”
JAVA_OPT=“${JAVA_OPT} -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35”
关键 JVM 参数说明：

参数 建议值 说明
-Xms / -Xmx 堆内存的 50%-60% 不超过 32GB，避免 GC 停顿
GC 算法 G1GC 适合大堆内存，停顿可控
-XX:MaxGCPauseMillis 20ms 控制 GC 停顿时间
堆外内存 剩余内存用于 PageCache 加速消息读写
RocketMQ 操作命令大全（mqadmin）
mqadmin 是 RocketMQ 最强大的运维工具。几乎所有命令都需要 -n 指定 NameServer 地址。

常用命令分类：

Topic 管理：

命令 用途 示例
updateTopic 创建/更新 Topic ./mqadmin updateTopic -n 127.0.0.1:9876 -t order_topic -b 192.168.1.20:10911
deleteTopic 删除 Topic ./mqadmin deleteTopic -n 127.0.0.1:9876 -t order_topic
topicList 查看所有 Topic ./mqadmin topicList -n 127.0.0.1:9876
topicStatus 查看 Topic 状态 ./mqadmin topicStatus -n 127.0.0.1:9876 -t order_topic
topicRoute 查看 Topic 路由 ./mqadmin topicRoute -n 127.0.0.1:9876 -t order_topic
集群与 Broker 管理：

命令 用途 示例
clusterList 查看集群状态 ./mqadmin clusterList -n 127.0.0.1:9876
brokerStatus 查看 Broker 状态 ./mqadmin brokerStatus -n 127.0.0.1:9876 -b 192.168.1.20:10911
brokerConsumeStats 查看消费统计 ./mqadmin brokerConsumeStats -n 127.0.0.1:9876 -b 192.168.1.20:10911
消费组管理：

命令 用途 示例
consumerProgress 查看消费进度 ./mqadmin consumerProgress -n 127.0.0.1:9876 -g order_consumer_group
consumerStatus 查看消费者状态 ./mqadmin consumerStatus -n 127.0.0.1:9876 -g order_consumer_group
consumerConnection 查看消费者连接 ./mqadmin consumerConnection -n 127.0.0.1:9876 -g order_consumer_group
消息管理：

命令 用途 示例
queryMsgById 按 ID 查消息 ./mqadmin queryMsgById -n 127.0.0.1:9876 -i msgId
queryMsgByKey 按 Key 查消息 ./mqadmin queryMsgByKey -n 127.0.0.1:9876 -t order_topic -k order_123
queryMsgByOffset 按偏移量查消息 ./mqadmin queryMsgByOffset -n 127.0.0.1:9876 -t order_topic -b 192.168.1.20:10911 -i 0
💡 小贴士：所有命令都可以加 -h 获取详细帮助。如果同时配置了 -b（Broker 地址）和 -c（集群名），优先使用 -b。

RocketMQ 常用运维脚本与工具
启动/停止脚本：

启动 NameServer

nohup sh bin/mqnamesrv &

启动 Broker

nohup sh bin/mqbroker -c conf/broker.conf &

停止 NameServer

sh bin/mqshutdown namesrv

停止 Broker

sh bin/mqshutdown broker
查看日志：

Broker 运行日志

tail -f ~/logs/rocketmqlogs/broker.log

NameServer 日志

tail -f ~/logs/rocketmqlogs/namesrv.log

存储错误日志

tail -f ~/logs/rocketmqlogs/store.log
RocketMQ Dashboard：官方提供的 Web 控制台，支持 Topic 管理、消费者管理、消费进度查看、消息查询等功能。

部署 Dashboard

git clone https://github.com/apache/rocketmq-externals
cd rocketmq-console
mvn clean package -Dmaven.test.skip=true
java -jar target/rocketmq-console-ng-*.jar --rocketmq.config.namesrvAddr=192.168.0.1:9876
Broker 扩缩容与平滑迁移
扩容场景：业务增长，需要增加 Broker 节点分担压力。

扩容步骤：

image

缩容场景：节点下线，需要先将该节点上的数据迁移走。

缩容步骤：

将要下线的 Broker 上的 Topic Queue 逐步迁移到其他 Broker
等待该 Broker 上的消息全部被消费完（或手动清理）
关闭 Broker 进程
从 NameServer 路由中自动剔除
平滑迁移（集群迁移/版本升级）：

使用双写或灰度方式，新老集群并行运行
通过路由控制组件动态切换客户端的读写流量
整个过程不中断消息生产与消费
集群升级的灰度策略与回滚方案
升级策略：
image

回滚方案：

预置回滚脚本：一键切回旧版本配置
回滚时自动清理灰度期间产生的积压消息
保留旧版本包：升级前备份，回滚时直接替换
消费者灰度发布：

为不同批次的消费者实例设置部署标识（环境标签、版本号）
分批重启，不要同时重启所有消费者实例
确保灰度消费者和正常消费者使用相同的订阅关系
十四、监控与告警
监控体系架构概览
一个完整的 RocketMQ 监控体系应该是分层的：

image

RocketMQ Console（Dashboard）的使用
RocketMQ Dashboard 是官方提供的 Web 控制台。

部署方式：

git clone https://github.com/apache/rocketmq-externals
cd rocketmq-console
mvn clean package -Dmaven.test.skip=true
java -jar target/rocketmq-console-ng-*.jar --rocketmq.config.namesrvAddr=192.168.0.1:9876
核心功能：

功能 说明
驾驶舱 查看 Broker、Topic 的消息量
Topic 管理 查看、创建、删除 Topic
消费者管理 查看 Consumer Group、订阅关系
消费进度 查看积压量（consumerProgress）
消息查询 按 MsgId 或 Key 查询消息
Broker 状态 查看 Broker 是否在线
局限性：

仅支持基础状态查看，无历史趋势图
无告警功能
性能较差，不适合大规模集群
💡 小贴士：Dashboard 适合开发测试和简单运维，生产环境建议配合 Prometheus + Grafana 使用。

Prometheus + Grafana 监控体系集成
这是生产环境推荐的监控方案。

整体架构：

image

部署步骤：

步骤 1：配置 RocketMQ 开放监控指标

RocketMQ 自身已内置监控指标，需通过配置开启。

步骤 2：部署 RocketMQ Exporter

下载 rocketmq-exporter

wget https://github.com/apache/rocketmq-exporter/releases/download/rocketmq-exporter-0.0.2/rocketmq-exporter-0.0.2.jar

启动 Exporter

java -jar rocketmq-exporter-0.0.2.jar --rocketmq.config.namesrvAddr=127.0.0.1:9876
RocketMQ Exporter 将集群指标以 Prometheus 格式通过 HTTP 接口暴露。

步骤 3：配置 Prometheus 采集

prometheus.yml

scrape_configs:

• job_name: ‘rocketmq’
  static_configs:
  • targets: [‘localhost:5557’] # Exporter 端口
    步骤 4：Grafana 配置数据源和仪表盘

添加 Prometheus 数据源
导入 RocketMQ 官方 Dashboard（或社区模板）
💡 小贴士：生产环境建议将 Prometheus 和 Grafana 部署在独立于业务集群的监控专用服务器上。RocketMQ Exporter 版本需与 RocketMQ 版本匹配。

消息积压监控与告警配置
核心监控指标：

积压消息数：Topic 中未消费的消息总量
消费延迟：消息产生到被消费的时间差
消费 TPS vs 生产 TPS：判断消费是否跟得上生产
告警规则示例（Prometheus）：

groups:

• name: rocketmq_alerts
  rules:

  积压超过 10 万条告警

  • alert: RocketMQMessageBacklog
    expr: rocketmq_consumer_pending > 100000
    for: 5m
    annotations:
    summary: “RocketMQ 消息积压超过 10 万条”

  消费延迟超过 5 分钟告警

  • alert: RocketMQConsumeDelay
    expr: rocketmq_consumer_lag > 300
    for: 5m
    annotations:
    summary: “RocketMQ 消费延迟超过 5 分钟”
    处理建议：

排查是否有闲置消费组，如果有则删除
增加消费者组内消费者数量
优化消费逻辑，缩短单条消息处理时间
消费延迟监控
消费延迟是比积压量更敏感的指标——它直接反映了消息从产生到被消费的时间差。

监控方式：

通过 Dashboard：查看 consumerProgress 中的延迟数据
通过 Prometheus：rocketmq_consumer_lag 指标
通过消息轨迹：对比消息的存储时间和消费时间
image

Broker 磁盘容量监控
磁盘满了是 RocketMQ 生产环境最常见的故障之一。

监控指标：

磁盘使用率（建议 < 75%）
CommitLog 目录大小
ConsumeQueue 目录大小
告警规则：

• alert: RocketMQDiskUsage
  expr: (1 - node_filesystem_avail_bytes{mountpoint=“/data”} / node_filesystem_size_bytes{mountpoint=“/data”}) > 0.85
  for: 5m
  annotations:
  summary: “RocketMQ 磁盘使用率超过 85%”
  处理方案：

检查 fileReservedTime 配置是否过大
手动清理过期消息（通过调整保留时间）
扩容磁盘或迁移数据
消息生产 TPS / 消费 TPS 监控
TPS 监控帮助判断系统是否处于正常负载状态。

指标 含义 异常信号
生产 TPS 每秒写入消息数 突增 → 可能有流量突刺；突降 → Producer 可能有问题
消费 TPS 每秒消费消息数 持续低于生产 TPS → 积压在增加
TPS 比值 消费 TPS / 生产 TPS < 1 → 消费能力不足
消息轨迹监控与异常告警
消息轨迹记录了消息从生产到消费的完整链路。

开启方式（Broker 配置）：

traceTopicEnable=true
msgTraceTopicName=RMQ_SYS_TRACE_TOPIC
监控告警场景：

消息发送失败率过高 → 检查 Producer 或 Broker
消息消费失败率过高 → 检查业务逻辑或下游依赖
消息长时间未被消费 → 检查消费者是否在线
死信队列监控与人工处理
死信队列（DLQ）中的消息需要独立监控和人工处理。

监控方式：

通过 RocketMQ Exporter 监控 DLQ 的 Offset 变化
配置 Prometheus 告警：DLQ 有消息时触发告警
处理流程：

image

十五、故障排查与调优
消息发送超时的原因与排查
常见原因：

原因 排查方法 解决方案
Broker 响应慢 查看 Broker 的 broker.log，检查 GC 日志 优化 JVM 参数，扩容
网络延迟高 ping 测试，检查网卡流量 检查网络设备，优化网络配置
磁盘 IO 高 iostat 查看磁盘利用率 换 SSD，优化刷盘策略
消息体过大 检查消息大小 压缩消息体，或存 OSS
NameServer 连接不上 检查 namesrv.log 检查 NameServer 是否存活
排查流程图：

image

消息消费积压的排查与处理
消息积压是生产环境最常见的问题。

积压原因分析：

image

处理方案：

方案 适用场景 操作
扩容消费者 消费者数量 < Queue 数量 增加 Consumer 实例
临时丢弃消息 非关键业务，积压严重 跳过部分非核心消息
新 Topic 间接扩容 Queue 数量不足 创建新 Topic 分流
优化消费逻辑 单条消息处理慢 减少 RPC 调用，异步化
临时关闭非关键消费 核心业务积压 优先保障核心消息
💡 小贴士：积压处理的核心原则是 “先止损，再定位” 。先让消费速度追上，再分析根本原因。

消息重复消费的排查与幂等处理
RocketMQ 保证 “至少一次（At Least Once）” 语义，意味着消息可能重复消费。

重复消费的常见场景：

Rebalance 时：Queue 重新分配，Offset 未及时提交
网络抖动：Broker 响应超时，Producer 重试发送
消费者重启：Offset 提交失败，重新拉取
Broker 重启：部分消息被重新投递
幂等处理的几种方案：

image

排查方法：

查看消息轨迹，确认消息是否被多次消费
检查 Consumer 日志，看是否有重复处理记录
检查 Rebalance 日志，确认是否频繁触发
消息丢失的排查与防范
消息可能在三个环节丢失：

image

防范措施：

环节 防范措施
生产阶段 使用同步发送，检查 SendResult；失败时重试；记录发送日志
存储阶段 同步刷盘（SYNC_FLUSH）；主从同步复制（SYNC_MASTER）
消费阶段 消费成功后手动提交 Offset；幂等处理
消息丢失排查流程：

检查消息轨迹，确认消息是否到达 Broker
检查 Broker 日志，看是否有刷盘异常
检查 Consumer 日志，看是否拉取到消息
使用 keys 字段定位丢失消息
CommitLog 文件损坏的恢复
RocketMQ 的文件恢复机制：

Broker 启动时，会自动检测 CommitLog 和 ConsumeQueue 的一致性
根据文件的魔数（Magic Code） 和文件大小进行校验
如果文件损坏，会跳过或删除损坏的文件
从 ConsumeQueue 和 IndexFile 中重新构建数据
恢复流程：

image

手动恢复建议：

停止 Broker
备份损坏的 CommitLog 文件
删除损坏文件，重启 Broker（自动恢复）
如果自动恢复失败，考虑从备份中恢复
Broker 内存 GC 优化
GC 问题的典型表现：

消息发送超时增加
Broker 日志中出现频繁的 GC 停顿
broker.log 中有 gc 相关警告
优化策略：

策略 说明
堆内存 ≤ 32GB 超过 32GB 会导致 GC 停顿过长
使用 G1GC 适合大堆内存，停顿可控
调整 -XX:MaxGCPauseMillis 建议 20ms
启用堆外内存 transientStorePoolEnable=true
监控 GC 频率 使用 jstat 或 GC 日志分析
GC 日志分析：

开启 GC 日志（JVM 参数）

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/logs/gc.log
网络抖动对消息收发的影响
网络抖动的影响：

发送超时：Producer 发送消息超时，触发重试
消息重复：网络重传导致消息重复
连接断开：客户端与服务端连接断开，需重连
消费延迟：Consumer 拉取消息超时
处理建议：

合理设置超时时间：根据网络状况调整 sendMsgTimeout
开启重试机制：利用 RocketMQ 的自动重试
幂等处理：业务层做好幂等
监控网络质量：使用 ping、traceroute 监控网络延迟和丢包
操作系统参数调优
RocketMQ 对操作系统参数敏感，默认 Linux 参数远低于生产要求。

文件句柄限制：

/etc/security/limits.conf

• soft nofile 655350
• hard nofile 655350
• soft nproc 655350
• hard nproc 655350
  RocketMQ 需要为 CommitLog、ConsumeQueue 和网络连接打开大量文件描述符，官方建议设置为 655350。

内核参数调优：

/etc/sysctl.conf

fs.file-max = 1000000 # 系统最大文件句柄数
vm.swappiness = 1 # 尽量使用物理内存，减少 swap
vm.dirty_ratio = 20 # 脏页比例
vm.dirty_background_ratio = 5
net.core.somaxconn = 32768 # 增大 socket 监听队列
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_fin_timeout = 30
磁盘调度器：

RocketMQ 推荐使用 deadline I/O 调度器，它能为请求提供有保证的延迟。

查看当前调度器

cat /sys/block/sda/queue/scheduler

设置为 deadline

echo deadline > /sys/block/sda/queue/scheduler
禁用透明大页（Transparent Huge Pages）：

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
常见异常错误码与解决方案
错误码/异常 原因 解决方案
RemotingTimeoutException 发送超时 增大超时时间，检查 Broker 负载
RemotingConnectException 连接 Broker 失败 检查 Broker 是否存活，网络是否连通
MQClientException: No route info 无路由信息 检查 Topic 是否存在，Broker 是否注册
MQBrokerException: TOPIC_NOT_EXIST Topic 不存在 先创建 Topic 再发送
MQBrokerException: SERVICE_NOT_AVAILABLE Broker 服务不可用 检查 Broker 状态和资源
RemotingSendRequestException 网络发送失败 检查网络连接
TopicMessageType validate failed 5.x 消息类型校验失败 使用正确的消息类型或 5.x gRPC 协议
Broker 禁止自动创建 Topic 未开启自动创建 手工创建 Topic
通用排查思路：

查看 Broker 日志（~/logs/rocketmqlogs/broker.log）
查看 NameServer 日志（~/logs/rocketmqlogs/namesrv.log）
检查网络连通性（telnet、ping）
检查系统资源（磁盘、内存、文件句柄）
检查配置是否正确（Topic、Group、NameServer 地址）
小结
这篇文章是 RocketMQ 系列的最后一篇，涵盖了部署与运维的方方面面，通过 10+ 张流程图，我们搞清楚了：

集群部署与高可用：

单机部署、多 NameServer 部署、主从集群部署的完整流程
Dledger 高可用架构的自动切换机制
多机房多活的两种方案
硬件配置、JVM 参数调优的实战建议
mqadmin 命令大全和常用运维脚本
监控与告警：

Dashboard 的基础监控功能
Prometheus + Grafana 的高级监控体系
消息积压、消费延迟、磁盘容量、TPS、死信队列的监控与告警