rocketmq1:集群主要结构和监控，以及性能测试与成本控制

(1). rocketmq集群主要结构

官方推荐的部署结构是2master-2slave+2namesrvs，master与slave的同步支持async/sync两种方式。

1.对于mq使用必须了解的重要组成部分：

topic, producer, producerGroup; consumer, consumerGroup, consumerQueue。

topic：消息主题。

producer：消息生产者，发送消息；一个topic可以有多个消息来源/生产者。

consumer：消息的消费者，接收消息；一个topic可以有多个消费者。

producerGroup：

对producer分组。

以订单为例说明其必要性，订单消息的产生分布在多个系统，我们需要对每个系统发出的订单消息分类，方便我们统计一个topic下不同消息来源的producer的相关指标数据，如不同订单系统发送订单消息的TPS等。

结合grafana+prometheus编程，可以很直观的将各个系统的orderProducer监控起来。

consumerGroup：

对consumer分组。

同样还以订单为例，同一个订单消息会被多个系统同时消费，我们需要对每个系统发出的订单消息分类，方便我们统计一个topic下不同消费者的相关指标数据，如消息被消费的TPS等。

结合grafana+prometheus编程，可以很直观的将各个系统的orderProducer监控起来。

consumerGroup和producerGroup的作用：

a.一方面可以监控业务中的producer和consumer的运行状态；

b.另一方面也是对rocketmq集群的保护，由于所有topic的消息的内容都存在一个文件里，所以如果不同topic的消费速度存在很大差异时，会造成随机IO飙升，使得集群的性能出现不稳定。

做法也很简单，结合grafana+prometheus编程，将他监控起来，同时加入报警。

2.commitlog&queuelog：

所有消息都存在这个commitlog文件中，按照大小切分,queuelog中记录每条消息在commitlog中的位置等信息;

这也是为什么rocketmq比kafka性能好很多的原因，rocketmq存放消息的只有一个文件，但是kafka是一个partition一个消息文件，rocketmq的随机IO<<kafka。

kafka主要还是用于日志，topic少(partitions少)；rocketmq主要用于业务，因为会有很多的topic；两者的面向场景还是有很大差异的。

3.consumerOffset：

用于记录每个consumer消费消息的位置。

但是要注意：rocketmq的存储结构决定了一个queue只能分配给一个consumer，因为只有这样consumer对queue的消息的消费位置的提交才不会冲突(注1)，所以当consumer数量多于queue数量时，多于的consumer不会工作。

注1：如果要保证多个consumer对同一个queue的offset提交不会冲突，这个太复杂了，性能也会大幅下降，没有mq会这么做。

数据格式如下(很好理解)：

(2). rocketmq监控

rocketmq的监控包含三部分：

a.prometheus编程监控producer和consumer+grafana展示+报警；

b.自己写脚本监控topic积压数量+报警；

c.官方rocketmq-console提供admin后台级别的数据监控(没有报警)；

这里展示a和b:

a.prometheus+grafana监控rocketmq

c.官方rocketmq-console

官方的这个console是很强大的，支持非常多的维度数据，涵盖几乎所有指标，这里取其一举例。

(3). 性能测试

性能测试也是一个很讲究工程学的问题，这里只列出最终采用的架构所对应的测试用例，后边有时间单开一章讨论rocketmq性能测试的设计和实践。

(4). 成本控制

架构/基础组件的定型过程中，成本是相当重要的环节，即性价比问题。

下图中的成本部分数字做了加权混淆修正。

从上图中，我们很明显可以看到，换SSD磁盘没有必要，费用上升很多，实际中只有遵循成本的工程策略，才能把费用降下来，钱都是这么省出来的；

一定要有成本意识。

后边有时间会深入rocketmq各个环节去探究。

结束。