当前位置:   article > 正文

RocketMQ控制台使用

rocketmq控制台使用

参考链接:RocketMQ之console监控平台使用详解(三) - 老郭种树-老郭种树

二、模块

1.OPS

这里很容易看清楚,双击标签可以修改NameSerIP+Port。这里我测试过修改端口,发现重新发送一样的消息,还是能消费。

其实也能理解,因为NameSer改变了,也只是使得Broker不能从本地获取最新的路由信息。但是本地还是缓存了路由信息,所以一样的Topic还是能获取到路由信息,可以获取到路由信息还是能发送到Brokder

所以这里我的测试是一次失败的对照测试,但是这个模块平时需求不大,就过了。

2.Dashboard

此图表较简单,其实是指所有Brokder处理消息的数量。比如从上图可以看出来,我只有一个Brokder,并且此Brokder处理了6条消息。

此图标可以筛选出某个Topic下5分钟的消息数量。但是可以切换时间,所以就相当于可以查看某个Topic下的消息数量趋势。

这条趋势曲线有时候貌似不准确,测试过几次有一次在那个时间点并没有变化。

3.Cluster

4.jpg

这里有点坑,Cluster翻译过来叫集群。这里并不是指消费模式中的集群消费,而是指Brokder的集群部署

但是我这里并没有使用Broker的集群部署,所以只有一条数据。如果有多个broker那这里应该有多行数据。

每一行中各项代表的意思如下

  • Broker — Broker的名字
  • Address — 地址
  • Today Produce Count — 今天发送的消息数量
  • Today Consume Count —- 今天消费的消息数量

4.Topic

Topic算是重点之一。

5.jpg

这里的ADD/UPDATE是有作用的,可以在这里添加一个Topic,经过测试,感觉在这里意义不大。这里涉及到消息的发送消费与TopicBroker的关系,下篇文章分析。

每一行的Topic分成如下几个操作按钮

6.jpg

点击第一个[status]按钮。显示如下界面。可以从中获取的信息比较多。该消息队列TopicBrokerNamequeueId

这里涉及到发送消息的原理。简单来说

通过一个Topic可以获取到对应的路由信息,路由信息里面维护了消息队列集合,而我们发送消息其实就是通过消息队列发送

消息队列集合是个集合,所以也是有集合的属性。其中每一项就是消息队列,就是如下图的每一行,每一行在集合中的位置就是queueId

7.jpg

点击第二项是保存在NameSer的路由信息。

7.jpg

这里可能要注意下。保存在NameServer的路由信息和本地缓存的不一样,本地缓存的属性内容更丰富更多。看看源码吧!

保存在NameSer的路由对象


  
  
  1. public class TopicRouteData extends RemotingSerializable {
  2. private String orderTopicConf;
  3. private List< QueueData> queueDatas;
  4. private List< BrokerData> brokerDatas;
  5. private HashMap< String /* brokerAddr */, List< String> /* Filter Server */> filterServerTable;
  6. }
  • 1

发现没,其中包含的属性和如上图片类似。

queueDatasbrokerDatas,其中queueDatas包含消息队列的基本情况,读/写的最大数目,brokerDatas包含Broker的位置信息。

再看看本地的真正路由信息,如上对象是它的属性。


  
  
  1. public class TopicPublishInfo {
  2. private boolean orderTopic = false;
  3. private boolean haveTopicRouterInfo = false;
  4. private List<MessageQueue> messageQueueList = new ArrayList<MessageQueue>();
  5. private volatile ThreadLocalIndex sendWhichQueue = new ThreadLocalIndex();
  6. private TopicRouteData topicRouteData;
  7. }
  • 1

这下很明白了。

第三项[Consumer Manage],看名字也知道啥意思,该Topic的消费管理。

第四项[Topic Config],修改Topic的属性,没啥作用,本来代码也可以控制。

第五项[Send Message],向该Topic发送消息。可以测试玩玩,将Consumer配置好,然后运行,不通过代码发送,在这里发送消息,Consumer也能接受到。

9.jpg

10.jpg

5.Consumer

11.jpg

没太看懂这每一行代表啥意思。估计是一个Consumer对象。后面几个按钮点击后,可以看看该Consumer的具体配置信息,好像没啥东西。

6.Message

该模块很重要,信息量也很多。

12.jpg

比较容易理解,根据如上三项对Message分组查询。一般第一项根据Topic查询比较多。因为据说根据key去查询有坑。建议idTopicid因为唯一最简单。

13.jpg

这是该Topic下的所有消息,不管是否消费都在内。

Message ID 、Tag 、Key都是消息比较重要的属性。点击右方的按钮,可以看到该消息更加具体的情况。

14.jpg

注意点都用箭头标出来了,其他可能比较容易理解,无非就那几个属性。最后的TrackType很重要,对于排查问题。该属性的值有好几个,现在看到的几个总结如下

  • CONSUMED 代表该消息已经被消费
  • NOT_CONSUME_YET 还没被消费
  • UNKNOW_EXCEPTION 报错了,可以看日志,一般报错内容会紧跟其后,具体很容易排查出来
  • NOT_ONLINE 代表该Consumer并没有运行

总共有如下几个


  
  
  1. public enum TrackType {
  2. CONSUMED,
  3. CONSUMED_BUT_FILTERED,
  4. PULL,
  5. NOT_CONSUME_YET,
  6. NOT_ONLINE,
  7. UNKNOWN,
  8. }
  • 1
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/从前慢现在也慢/article/detail/256851
推荐阅读
相关标签
  

闽ICP备14008679号