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