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硬盘。

博主：测试生财

座右铭：专一测试与自动化，致力提升研发效能；经过测试精进完成原始积累，经过读书理财奔向财务自由。

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

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

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