一起了解rocketmq的性能,以及阿里是如何应用rocketmq的。
消息生产者,负责产生消息,一般由业务系统负责产生消息。
消息消费者,负责消费消息,一般是后台系统负责异步消费。
消息主题,负责标记一类消息,生产者将消息发送到Topic,消费者从该Topic消费消息。
消息中转角色,负责存储消息,转发消息,一般也称为 Server,在 JMS 规范中称为 Provider。
服务发现Server,用于生产者和消费者获取Broker的服务。
每秒钟Broker接收或者投递的消息条数。
这个图在明白不过了吧。 1) Producer 和 Consumer 与NameServer要建立长连接。 2)Topic里面的NameServer地址找到对应的Broker。 3)在实际中Producer,Consumer,NameServer都不是单点的。
1) MQ真正用来投递和转发消息的组件是Broker,因此压测的对象是Broker。 2) MQ Broker组件吞吐量理论上来说具有水平扩展能力,即N台Broker是单台Broker吞吐量的N倍,因此压测通常部署单个节点Broker。 3) NameServer通常用来客户端服务发现,消息收发的请求对NameServer基本没有压力,因此测试过程中NameServer可单点部署。
真实的环境nameserver是2个,一个nameserver不工作另一个nameserver可以提供正常的服务。阿里一般部署4个为了容灾。
接收的能力其实就是producer集群发送信息的量,rocketMq端启动多个Broker来进行发送消息,在这种情况下没有消息端,纯粹来看broker接收消息的能力,为什么把这种场景单独列出来,也就是在以往的测试过程中,broker瓶颈是在接收消息这里,消费对于broker一般没有什么压力,它只要把消息投递出去就可以了,但是对于接收消息,它需要把请求进行反序列化,做个存储,这个非常消耗硬件的资源,所以通常来说broker接收消息的能力远小于他的投递能力的,消息的接收能力也是broker最重要的指标之一,所以一般情况把接收消息的能力单独放在一个场景下进行测试。有时候项目比较赶,其实很多时候只做消息发送的测试就足够了。
这个更加符合我们使用的场景:为了测试Broker同时接收和投递消息的能力,Producer以及Consumer通过NameServer连接到Broker,每个Producer的逻辑即无限循环无间断发送消息,Consumer等待消息投递;
三大类:客户端的因素,客户端本身应用的因素,硬件的配置。 1.客户端因素
1)连接数少量(<1万) 2)连接数较多(1万<10万) 3)连接数大量(>10万)
什么叫消息投递比呢,即一条消息要被几个应用订阅,即一条消息Broker需要投递给多少订阅端,如一个Topic有1个group的消息费端来订阅,则消息投递一次,有5个group,则消息需要投递5次。
刷盘:保存到内容就返回,写内存的速度高于写磁盘的速度。
相同配置的物理机优于虚拟机。高配置的机器优于低配置的机器A8系列的物理机优于S7、S9系列的物理机。
网卡1000Mb,全双工,出口入口均为125MB
即磁盘的读取以及写入速度依赖于磁盘的转动速度以及读写的位置,读写越随机则性能越低。
producer 发布了10条消息,第一个组消费了5条消息,第二个组消息8条,对于第一个组堆积了5条消息,第二个组堆积了2条消息。没有消费的消息就叫堆积。 内存不够的情况下,堆积的消息落到磁盘里面了,这时候从磁盘读开销IO很大,会跟消息的存储和其他IO进行竞争,竞争的结果影响整个的性能,异步刷盘,刷的很慢,同步就不说,肯定慢死,发送端的性能下降,消费也很慢。一个消费的堆积可能蝴蝶效应打垮整个mq的服务。所以尽可能不让消费端进行堆积,有报警机制。是不是消费端卡住了,消费端消费不过来了,需要进行消费端的扩容,反正尽量不要堆积。防止堆积。10万的流量,一个机器可以处理5万的流量,不是正好上2台这种刚刚好的情况,而是上10台或者是8台。虽然整体的性能下降但是可以保证系统的稳定性。冗余的重要性。
PS:对于架构来说rocketMq的性能至关重要,只要用到消息队列的都是比较核心的应用,所以很多东西需要处理。