背景

最近公司的项目中使用rocketmq,部署方式为多master-多slave。项目上线一周后,有一天调用方的开发突然找我,说我们的MQ服务的请求调用有延时。

我登陆到broker的机器上查看了broker的store.log,发现pagacache的大部分响应都在0~50ms,有部分请求在100ms~200ms。看来broker集群的负载有些高了。

方案

我和几个开发对了下应对方案:

一是通过扩容broker集群降低broker的处理压力

二是优化当前的broker配置来提升性能

最终考虑到扩容机器的经费比较贵,当前又处于上线初期,服务的稳定性大于消息的可靠性,因此决定使用第二种方案。

通过查看配置和分析最终选择了优化brokerRole和flushDiskType这两项。

优化过程

配置详解

brokerRole分为两种

SYNC_MASTER:如果是同步模式,master和slave之间的数据同步要求较为严格,保证尽量不丢消息,性能会有损耗

ASYNC_MASTER:如果是异步模式,master和slave之间的数据同步要求较为宽松,极端情况下可能会丢消息,但是性能较好

flushDiskType也分两种:

SYNC_FLUSH:同步刷盘模式,当消息来了之后,尽可能快地从内存持久化到磁盘上,保证尽量不丢消息,性能会有损耗

ASYNC_FLUSH:异步刷盘模式,消息到了内存之后,不急于马上落盘,极端情况可能会丢消息,但是性能较好。

配置优化

之前我搭建的broker的配置中,配置的是同步复制和同步刷盘:

brokerRole=SYNC_MASTER

flushDiskType=SYNC_FLUSH

然后我修改为:

brokerRole=ASYNC_MASTER

flushDiskType=ASYNC_FLUSH

修改完之后,依次重启broker(注意时间重启多个broker之间要保留一定的间隔时间)

优化效果

我打开了之前搭建的Pro0methues的监控(如下图),看了下PutMessageDistributeTime这一项:

这张图最左边的两个数据区间是优化前的,我们可以看到绝大多数处理在黄色和天蓝色区间(0~50ms),还有部分请求处于100ms~200ms的区间。

优化后的效果是,绝大多数都处于绿色区间(0ms),表明broker极快地完成了处理。同时也没有50ms以上长尾请求了。

建议:

1. 如果机器不够富足,且可以容忍一些消息丢失。可以通过异步复制和异步刷盘大幅提升性能。

2.如果不能容忍消息丢失,建议遇到处理响应较慢的时候扩容broker集群,另外请尽量使用ssd硬盘。


博主:测试生财

座右铭:专注测试与自动化,致力提高研发效能;通过测试精进完成原始积累,通过读书理财奔向财务自由。

csdn:https://blog.csdn.net/ccgshigao

博客园:https://www.cnblogs.com/qa-freeroad/

51cto:https://blog.51cto.com/14900374