消息队列常用命令速查表 - Kafka/RabbitMQ/RocketMQ 命令大全
消息队列的事故很少是「挂了」，更多是「不消费」「积压」「连接数只涨不降」这类慢性病。定位顺序有固定套路：先看 lag 或队列深度判断积压，再看消费者数量与状态区分「没人消费」和「消费太慢」，然后用连接列表确认是应用侧连接池没回收还是 Broker 侧异常。Kafka、RabbitMQ、RocketMQ、Redis Pub/Sub 四套命令各有各的观察口径，不能混用结论——例如 Redis Pub/Sub 在客户端断开期间的消息直接丢，没有 lag 可看，排查思路要换成确认消费者是否在线。表里按积压、连接、集群巡检、压测四类场景分组，并给出 kafka-producer-perf-test 这类压测命令的限速与条数参数。遇到积压先判断成因，别用清队列掩盖问题。
Kafka 6
kafka-consumer-groups.sh --bootstrap-server :9092 --listkafka-consumer-groups.sh --describe --group <group>kafka-topics.sh --describe --topic <topic>kafka-topics.sh --create --topic <t> --partitions 3 --replication-factor 2kafka-console-producer.sh --topic <t> --bootstrap-server :9092kafka-console-consumer.sh --topic <t> --from-beginning --group <g>RabbitMQ 6
rabbitmqctl list_queues name messages consumersrabbitmqctl list_connections name state channelsrabbitmqctl list_channels pid numberrabbitmqctl cluster_statusrabbitmqadmin get queue=<q> count=1 ack=falserabbitmqctl list_exchanges name type / list_bindingsRocketMQ 5
mqadmin consumerProgress -g <group>mqadmin topicList -mmqadmin clusterListmqadmin brokerConsumeStats -b <addr> -g <group>mqadmin queryMsgById -i <msgId>Redis Pub/Sub 5
PUBLISH channel "message"SUBSCRIBE channel1 channel2PSUBSCRIBE news.*PUBSUB CHANNELS *PUBSUB NUMSUB channel通用积压与连接排查 5
kafka-consumer-groups.sh --describe --group <g> --staterabbitmqctl node_health_checkss -tnp | grep :9092 | wc -ldu -sh /var/lib/kafka /var/lib/rabbitmqjournalctl -u kafka --since "10 min ago"性能测试与压测 5
kafka-consumer-perf-test.sh --bootstrap-server :9092 --topic <t> --messages 1000kafka-producer-perf-test.sh --topic <t> --num-records 100000 --throughput -1rabbitmq-perf-test --queue <q> --rate 1000 --producers 5redis-benchmark -h host -t publish,subscribe -n 100000kafka-consumer-groups.sh --describe --group <g> --members --verbose命令示例
用消费组视图判断积压性质：分组看 LAG 与成员分配
kafka-consumer-groups.sh --bootstrap-server :9092 --list
kafka-consumer-groups.sh --describe --group <group> --members --verboseLAG 为 0 的分区说明已经被覆盖，全部 LAG 压在同一个消费者上——加消费者实例不会分流，因为分区数限制了并行度。真正的解法通常是先扩分区再加消费者。
输出
order-consumer inventory-consumer GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID order-consumer orders 0 48102 48310 208 order-consumer-1-9f2c order-consumer orders 1 47880 48311 431 order-consumer-1-9f2c order-consumer orders 2 48311 48311 0 Consumer group 'order-consumer' has 1 active consumer.
RabbitMQ 一次区分「无人消费」与「消费慢」
rabbitmqctl list_queues name messages consumersorders 的 messages 高而 consumers 为 0，属于注册或连接侧问题；emails 有 3 个消费者且积压很小，属于正常消化。两种形态的处置完全不同，所以先把它们分开比直接清队列重要。
输出
Listing queues for vhost / ... name messages consumers orders 15230 0 emails 18 3
按消息 ID 反查：确认消息是否真的进了 Broker
mqadmin queryMsgById -i <msgId>查得到说明生产端已落盘，问题在消费侧；查不到则是生产端就没发出去或已被清理。用这个方法可以把「消息丢了」的责任边界先划清，再去查对应一侧的日志。
输出
Topic: ORDER_CREATED | Queue: BROKER_MSG_QUEUE_ID_0 | Offset: 48310 | Size: 214 bytes | QueueOffset: 15230
压测前先看清 topic 结构与集群角色
kafka-topics.sh --describe --topic <t>
mqadmin clusterListIsr 少于 Replicas 说明有副本不同步，此时压测得到的吞吐不代表正常状态，应先恢复副本同步。分区数也直接决定压测能压出的并发上限。
输出
Topic: orders TopicId: 7Lk-9pQ2x PartitionCount: 3 ReplicationFactor: 2 Configs: Topic: orders Partition: 0 Leader: 2 Replicas: 2,1 Isr: 2,1 Topic: orders Partition: 1 Leader: 1 Replicas: 1,2 Isr: 1 Topic: orders Partition: 2 Leader: 2 Replicas: 2,1 Isr: 2,1
常见坑与注意事项
- 积压是症状不是原因：先用消费组视图与队列字段判断是消费者不足、消费过慢还是路由失败，直接清队列只会丢掉排障证据。
- 重启或重置 Broker 前确认持久化配置，未落盘的消息会直接消失，且事后无法从客户端侧补回。
- kafka-console-producer.sh 写入的是真实 topic，调试时务必确认 topic 名与业务隔离，否则会往生产流量里灌脏数据。
- rabbitmqadmin get 即使带 ack=false 也已经把消息移出队列头部，队首顺序被改变，频繁取样会打乱原有分发次序。
- kafka-producer-perf-test.sh --throughput -1 与 rabbitmq-perf-test 不限速时能在几秒内打满磁盘与网络，务必先确认是隔离环境再执行。
提示
- 消息积压先看 lag 和消费者数，确认是消费慢还是消费者不够，而不是直接清队列。
- 排查连接泄漏时同时看 list_connections 和应用侧连接池配置，单看一边容易误判。
- 重启 Broker 前确认消息是否持久化，未落盘的消息会直接丢失。
- Kafka 压测用 --throughput -1 表示不限速，配合 --num-records 测极限吞吐。
- Redis Pub/Sub 消息不持久化，客户端断开期间的消息会丢失，需要可靠投递用 Stream。
- RabbitMQ 队列积压时先看 consumers 列，为 0 说明消费者未注册或已断开。
- kafka-consumer-groups --describe --group G 的 LAG 列若持续增长而非回落，说明消费速率低于生产速率，不是瞬时抖动。
- rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers 可一次区分「无人消费」与「消费慢」。
- Redis Stream 的 XPENDING 配合 XINFO GROUPA 输出能定位卡住的消费者 ID，再决定是否 XCLAIM 转交。
常见问题
Kafka 的 LAG 列一直涨，是消费慢还是消费者不够？
先用 kafka-consumer-groups.sh --describe --group <group> 看清 LAG 是持续增长还是在回落：增长说明消费速率长期低于生产速率，缺口在扩大；只是短暂抬高又落回基线，才可能是瞬时抖动。再配合 --members --verbose 看消费组成员数与分区分配，如果空闲分区数大于 0，那属于「消费者不够、没分到分区」；如果分区都分满了 LAG 还在涨，那就是单个消费者处理太慢，加机器无效。
RabbitMQ 队列有消息但没被消费，先看哪几个字段？
用 rabbitmqctl list_queues name messages consumers 一次拿全。messages 有值而 consumers 为 0，说明消息进来了但没有任何消费者注册或已断开，先去查应用侧是否启动、是否连到了同一个 vhost。consumers 大于 0 仍不消费，则是消息没有路由到队列——此时 rabbitmqctl list_exchanges name type 和 list_bindings 能确认交换机类型与绑定关系，重点看是不是只声明了 exchange 而漏了 binding。
怎么区分连接泄漏在应用侧还是 Broker 侧？
两边都得看。Broker 侧用 rabbitmqctl list_connections name state channels 看连接与 channel 数量，再用 list_channels pid number 定位是哪条连接占了大量 channel——channel 远多于业务需求通常意味着连接没有复用。系统侧用 ss -tnp | grep :9092 | wc -l 统计到 Broker 的连接数，与应用配置的连接池上限对一下。Broker 侧连接数正常而系统侧持续增长，就是应用连接池没回收。
Redis Pub/Sub 的「消息丢了」为什么无从查证？
因为 Pub/Sub 没有持久化，也没有 offset。客户端在 SUBSCRIBE 期间断开会丢掉这期间的全部消息，PUBSUB CHANNELS * 只能看到当前活跃的频道，PUBSUB NUMSUB channel 也只报告当前订阅者数量——没有任何一个观测点能告诉你「错过了什么」。所以排查方向不是找消息，而是确认消费者是否在线、以及能否接受丢失；需要可靠投递就应换有消费组的方案而不是在 Pub/Sub 上想办法。
压测命令里的 --throughput -1 是什么意思？
表示不限速，让 kafka-producer-perf-test.sh 以系统能跑的最快速度灌数据，用来测吞吐上限而不是稳态延迟。配合 --num-records 100000 决定总条数。真实生产关心的是尾延迟时不该用它限速，而应设一个接近实际峰值的速率，否则测出来的「极限」跟线上毫无可比性。压测前先用 kafka-topics.sh --describe --topic <topic> 确认分区数，分区少会先撞上分区级瓶颈而不是 Broker 瓶颈。
由 巧匠 维护
公开更新于 2026年7月21日，内容持续校对官方文档。