1. 初识mqadmin:运维工程师的第一把钥匙
第一次接触RocketMQ的运维工作时,我被那一大堆管理命令整得头晕眼花。直到发现了藏在bin目录下的mqadmin工具,就像在迷宫里找到了指南针。这个命令行工具是RocketMQ官方提供的"瑞士军刀",能完成80%的日常运维工作。
记得第一次执行sh mqadmin时,屏幕上刷出的52个命令让我倒吸一口凉气。但实际工作中最常用的其实就十几个,我把它们分成几类:
- 主题管理:updateTopic、deleteTopic、topicList
- 消息查询:queryMsgByKey、queryMsgById、printMsg
- 消费组监控:consumerConnection、consumerProgress
- 集群管理:clusterList、brokerStatus
小技巧:所有命令都支持
-h参数查看帮助,比如mqadmin updateTopic -h会显示详细的参数说明。建议每次使用不熟悉的命令时先看帮助文档。
2. 主题管理:从创建到删除的全生命周期
2.1 创建主题的隐藏陷阱
上周我们业务上线新功能,需要创建一个名为payment_success的主题。看似简单的updateTopic命令,我踩了三个坑:
bash复制# 错误示范1:忘记指定集群名
mqadmin updateTopic -t payment_success -n 192.168.1.100:9876
# 报错:clusterName or brokerAddr must be specified!
# 错误示范2:队列数设置不合理
mqadmin updateTopic -c my_cluster -t payment_success -w 1 -r 1
# 导致消息堆积时无法横向扩展
# 最终正确的命令:
mqadmin updateTopic -c my_cluster -t payment_success \
-n 192.168.1.100:9876 \
-w 8 -r 8 -p 6 -o false
关键参数解析:
-w和-r:写队列和读队列数,建议设置为相同值,生产环境通常8-16个-p:权限控制,6表示读写权限(2写+4读)-o:是否顺序消息,支付场景设为false
2.2 主题排查三板斧
当监控报警显示主题异常时,我常用的诊断组合拳:
bash复制# 查看路由信息(确认broker分布)
mqadmin topicRoute -t payment_success -n 192.168.1.100:9876
# 检查状态(查看队列堆积)
mqadmin topicStatus -t payment_success -n 192.168.1.100:9876
# 列出集群所有主题(确认是否存在异常主题)
mqadmin topicList -n 192.168.1.100:9876
最近就靠这套命令发现了一个异常主题AD_HOUSE_TOPIC,是离职同事创建的测试主题,占用大量存储空间。用deleteTopic清理后,磁盘使用率立刻下降了30%。
3. 消息查询:定位问题的显微镜
3.1 四种查询方式对比
消息查询就像破案时的物证检查,RocketMQ提供了四种查询方式:
| 查询方式 | 命令示例 | 适用场景 | 响应速度 |
|---|---|---|---|
| 按Message ID | queryMsgById -i 7F000001... | 精确查找特定消息 | 最快 |
| 按Message Key | queryMsgByKey -k order_123 | 业务链追踪(如订单号) | 中等 |
| 按Offset | queryMsgByOffset -b broker-a | 已知物理位置时 | 快 |
| 按时间范围 | printMsg -b 20230101... | 模糊时间段的批量查询 | 最慢 |
实际案例:上周用户投诉订单状态未更新,通过订单号查询消息轨迹:
bash复制mqadmin queryMsgByKey -n 192.168.1.100:9876 \
-t order_status_update \
-k ORDER_20230715_001
# 输出显示消息被正常投递,问题出在消费端
3.2 消息体查看技巧
printMsg命令默认只显示元数据,要查看消息体需要加参数:
bash复制# 查看完整消息内容(包括body)
mqadmin printMsg -n 192.168.1.100:9876 \
-t payment_callback \
-i 0 -o 12345 \
-d true -c UTF-8
注意:消息体可能包含敏感信息,在生产环境使用时要遵守公司安全规范。我曾因为把含用户手机号的消息日志发到工作群,被安全部门约谈过。
4. 消费者组监控:消息链路的守门人
4.1 消费堆积告警处理
凌晨2点被报警吵醒:"consumer_group_x积压超过1w条!"。我的应急处理流程:
- 先用
consumerProgress确认堆积情况:
bash复制mqadmin consumerProgress -n 192.168.1.100:9876 \
-g consumer_group_x -s true
- 发现是其中两个队列堆积,用
consumerConnection检查消费者连接:
bash复制mqadmin consumerConnection -n 192.168.1.100:9876 \
-g consumer_group_x
-
发现有个消费者节点失联,联系对应团队重启服务
-
紧急情况下用
resetOffsetByTime重置offset:
bash复制mqadmin resetOffsetByTime -n 192.168.1.100:9876 \
-g consumer_group_x -t order_topic \
-s now -f true
4.2 消费者组配置优化
遇到过消费速度跟不上的情况,通过调整消费组配置解决:
bash复制# 增加重试队列数(默认1个)
mqadmin updateSubGroup -n 192.168.1.100:9876 \
-g consumer_group_x -q 3
# 开启从最小offset消费(防止跳过堆积消息)
mqadmin updateSubGroup -n 192.168.1.100:9876 \
-g consumer_group_x -m true
5. 集群运维:保持消息高速公路畅通
5.1 日常健康检查
我每天早上的例行检查清单:
bash复制# 检查集群状态
mqadmin clusterList -n 192.168.1.100:9876 -m
# 检查Broker状态
mqadmin brokerStatus -n 192.168.1.100:9876 -b 192.168.1.101:10911
# 监控关键指标
mqadmin statsAll -n 192.168.1.100:9876 -a
5.2 性能调优实战
某次大促前性能压测时,发现消息发送RT(响应时间)波动较大。排查过程:
- 用
checkMsgSendRT测试发送性能:
bash复制mqadmin checkMsgSendRT -n 192.168.1.100:9876 \
-t stress_test -a 1000 -s 1024
- 用
clusterRT监控集群整体响应:
bash复制mqadmin clusterRT -n 192.168.1.100:9876 \
-s 1024 -i 5 -p true
- 发现某台Broker的RT明显偏高,检查其配置:
bash复制mqadmin getBrokerConfig -n 192.168.1.100:9876 \
-b 192.168.1.102:10911
- 调整sendMessage线程池参数后恢复:
bash复制mqadmin updateBrokerConfig -n 192.168.1.100:9876 \
-b 192.168.1.102:10911 \
-k sendMessageThreadPoolNums -v 32
6. 安全与权限管理
6.1 ACL配置最佳实践
最近公司加强安全审计,要求对所有MQ资源做权限控制:
bash复制# 添加访问控制
mqadmin updateAclConfig -n 192.168.1.100:9876 \
-c my_cluster \
-a payment_service \
-s 5t4r0ngP@ssw0rd \
-t "payment_*=DENY,payment_success=SUB"
# 设置IP白名单
mqadmin updateGlobalWhiteAddr -n 192.168.1.100:9876 \
-c my_cluster \
-g "192.168.2.*,10.10.1.100"
血泪教训:曾经因为误操作
wipeWritePerm命令,导致整个集群不可写。现在执行高危命令前都会先在测试环境验证。
7. 实战问题排查案例
7.1 消息丢失之谜
收到业务反馈:"部分支付成功消息消失了!" 排查过程:
- 用
queryMsgByKey确认消息是否发送成功 - 用
brokerConsumeStats检查消费位点 - 发现是消费组重置offset导致,用
consumerStatus确认:
bash复制mqadmin consumerStatus -n 192.168.1.100:9876 \
-g payment_consumer -s
- 最终定位到是某开发同学手动重置了offset
7.2 磁盘爆满应急
凌晨收到磁盘报警,快速处理步骤:
- 用
cleanUnusedTopic清理废弃主题
bash复制mqadmin cleanUnusedTopic -n 192.168.1.100:9876 \
-b "192.168.1.101:10911;192.168.1.102:10911"
- 用
cleanExpiredCQ清理过期队列
bash复制mqadmin cleanExpiredCQ -n 192.168.1.100:9876 \
-c my_cluster
- 调整磁盘阈值防止再次出现
bash复制mqadmin updateBrokerConfig -n 192.168.1.100:9876 \
-c my_cluster \
-k diskMaxUsedSpaceRatio -v 85