rocketmq线上集群性能优化：异步刷盘与异步复制

背景

最近公司的项目中使用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硬盘。

传送门：2021最新测试资料与大厂招聘合集

博主：测试生财（一个不为996而996的测开码农）

座右铭：专注测试开发与自动化运维，努力读书思考写作，为内卷的人生奠定财务自由。

内容范畴：技术提升，职场杂谈，事业发展，阅读写作，投资理财，健康人生。

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

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

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

微信公众号：测试生财（定期分享独家内容和资源）