RocketMQ之Console介绍

不修边幅的创客 2020-09-19

2222

点击上方蓝色字体，选择“设为星标”

本文主要讲解RocketMQ运维平台的相关功能,通过对运维平台的介绍,有助于对RocketMQ的原理、规范使用的把握~

本文讲解的是RocketMQ 3.2.6版本,与4.x版本存在一定的差异~

一、Cluster

Cluster页主要介绍NameServer相关集群的状态,各个指标含义如下：

#Cluster Name #Broker Name #BID #Addr 来自Broker Server的配置；
#Version 标记了当前Broker Server的版本；
#InTPS #OutTPS 记录了当前Broker Server写入和读出消息的TPS；
#InTotalYest #OutTotalYest 记录了当前Broker Server昨天总共生产和消费的数量；
#InTotalToday #OutTotalToday 记录了今天截止到当前时间生产和消费的数量;

二、Topic

该页面主要是运维Topic相关的功能,包括创建Topic、查看Topic的状态、查看Topic路由信息、修改Topic信息、激活死信队列的消息。

其中:

1、%RETRY%+consumeGroup形式的队列是当前ConsumeGroup的重试队列 ,RocketMQ会为每个消费组都设置一个Topic名称为“%RETRY%+consumerGroup”的重试队列（这里需要注意的是，这个Topic的重试队列是针对消费组，而不是针对每个Topic设置的），用于暂时保存因为各种异常而导致Consumer端无法消费的消息。考虑到异常恢复起来需要一些时间，会为重试队列设置多个重试级别，每个重试级别都有与之对应的重新投递延时，重试次数越多投递延时就越大(messageDelayLevel决定)。RocketMQ对于重试消息的处理是先保存至Topic名称为“SCHEDULE_TOPIC_XXXX”的延迟队列中，后台定时任务按照对应的时间进行Delay后重新保存至“%RETRY%+consumerGroup”的重试队列中。

2、%DLQ%+consumeGroup是当前ConsumeGroup的死信队列,主要接受重试队列依然发送失败的消息,当一条消息初次消费失败，消息队列会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列不会立刻将消息丢弃,而是放到死信队列中。

1、Add => 创建Topic

创建Topic页面各参数含义如下：

writeQueueNums readQueueNums 可以不填写,默认是:8 一般情况下二者的数字相等,尽量避免:writeQueueNums > readQueueNums 因为可能有些消息消费不到,回头写一篇文章专门介绍；
Topic topic的写法不要太随意,要结合业务含义、集群等信息定义；
clusterName 指定把topic创建到哪个集群上,集群的所有broker都会创建；
brokerAddr 把topic创建到指定的某个broker上,不建议这样；
perm 默认:6,既可以生产也可消费；
order 消息是否有序,有序包括全局有序和局部有序,有时间专门写文章讲;

2、Update => 修改Topic

同上创建Topic ~

3、Stat => 查看Topic状态

前文讲过:RocketMQ之msgKey查询逻辑一条消息的落盘成功后要转发到IndexService构建msgKey的索引,还会在DefaultMessageStore.putMessagePositionInfo中构建消息的消费队列ConsumeQueue,一个消费队列是由topic和queueId构成,一个ConsumeQueue默认存储30W条消息,当有消费者消费时broker根据topic和queueId解析出要消费的ConsumeQueue,在根据consumeOffset从当前ConsumeQueue中获取消息的索引CommitLogOffset,从而获取数据返回给消费者。

含义如下: 当前Topic在某个broker server上的某个consumer queue(qid)的最小cosumeOffset和最大consumeOffset,而LastUpdated表示当前ConsumeQueue的最新一条数据进入消费队列的时间。

4、Route => 查看Topic路由信息

主要展示当前Topic所在的broker以及消息队列的情况。

5、Recover => 激活死信队列消息

点击Recover就是激活当前死信队列中的消息,触发重新消费。

三、Connection

在Connetion页中,通过输入消费者Group或者输入生产者Group和Topic可以查询消费者和生产者与Broker的连接状态。

1、ConsumerConnection

输入要查询的ConsumeGroup点击提交,即可查询连接情况,包括消费者地址(ClientAddr)、语言及其版本、Topic及Tags、消费模式及消费方式等。

2、ProducerConnection

同理查询生产者的连接,只是多了一个Topic,因为同一个生产者group可以往不同的Topic中发送消息,所以需要填写Topic。

四、Nameserv

主要是对NameServer相关的配置进行增删改,这里只介绍一个很重要的功能:WipeWritePerm(停写), 主要是把当前broker上的所有Topic的属性perm改成:2 ,修改30秒后所有连接到当前broker的生产实例做Rebalance,停止往该broker上的Topic写消息,该broker只提供读消息.该功能对于需要替换broker实例有帮助,在后面的集群的机房迁移中,会使用到该功能,让我们拭目以待。

五、Message

1、QueryMsgById

QueryMsgById主要是通过msgId查询消息,消息默认保存72小时,点击提交可以查询当前msgId的详情。如果你关心原理,请移步到:RocketMQ之msgId查询逻辑。

2、QueryMsgByKey

msgKey查询,需要输入topic和key,查询的结果有可能会有多条,这里返回的只是msgId,需要通过QueryMsgById在查询一次,如果你关心原理,请移步到:RocketMQ之msgKey查询逻辑。

3、QueryMsgByOffset

输入topic、brokerName、queue offset、queueId 查询关心的消息,原理大概如下:在broker-a中查找topic+queueId的ConsumeQueue消费队列,然后根据queue offset取出消息的CommitLogOffset,根据这个CommitLogOffset从CommitLog中即可得到消息。