RocketMQ on openEuler，是一種將 RocketMQ 消息中間件通過容器化的方式部署在 openEuler 操作系統(tǒng)上運(yùn)行，借助 openEuler 系統(tǒng)對于 OS 緩存回收效率增強(qiáng)的內(nèi)核特性，提升消息中間件在面向超大規(guī)模高并發(fā)、高吞吐量、低延遲場景下穩(wěn)定性和可靠性的軟件解決方案。

RocketMQ 消息隊列在穩(wěn)壓測試中遇到的 OOM 問題

移動云 RocketMQ 消息隊列產(chǎn)品正式上線前，通過壓測工具，創(chuàng)建多組生產(chǎn)者/消費(fèi)者進(jìn)程對 RocketMQ 獨(dú)享集群做多輪性能和穩(wěn)定性的壓力測試。

測試環(huán)境

壓測結(jié)果

在某次持續(xù)長時間的壓測過程中，發(fā)現(xiàn)消息收發(fā)吞吐，在一段時間內(nèi)的某一時刻會出現(xiàn)大幅度 TPS（生產(chǎn)/消費(fèi)）抖動下降的現(xiàn)象，并且是周期性的。

移動云 RocketMQ 消息隊列一直都比較穩(wěn)定運(yùn)行，為何在高并發(fā)的壓測下也會出現(xiàn) TPS 的抖動？我們初步懷疑是 CPU 負(fù)載或者 RocketMQ Broker 組件 GC 頻率過高導(dǎo)致，但通過查看 CPU 負(fù)載和 JVM GC 頻率并未發(fā)現(xiàn)任何異常。最終，經(jīng)過排查發(fā)現(xiàn)是由于 Broker Pod 進(jìn)程中的 buff/cache 在持續(xù)長時間壓測下不斷增加，系統(tǒng)無法及時有效回收，導(dǎo)致 Pod 中的運(yùn)行進(jìn)程占用內(nèi)存空間超出預(yù)先設(shè)置的 Limit 限制，觸發(fā)了 OOM Killer 機(jī)制重啟了 Broker Pod。

RocketMQ on openEuler—解決大規(guī)模高并發(fā)場景下提升穩(wěn)定性的新選擇

為何在持續(xù)高并發(fā)下進(jìn)行消息收發(fā)會導(dǎo)致系統(tǒng)的 buff/cache 的持續(xù)增加？通過翻閱操作系統(tǒng)手冊，可知 buff/cache 主要體現(xiàn)在系統(tǒng)的 PageCache 上。

PageCache 在 RocketMQ 消息存儲中的重要作用

PageCache 也叫頁緩沖或文件緩沖，在 linux 讀寫文件時，它用于緩存文件的邏輯內(nèi)容，從而加快對磁盤上映像和數(shù)據(jù)的訪問。

上圖中，紅色部分即為，PageCache。可見 PageCache 的本質(zhì)是由 Linux 內(nèi)核管理的內(nèi)存區(qū)域。平時我們寫的各種程序，通過 mmap 及 buffered I/O 將文件讀取到內(nèi)存空間實(shí)際上都是讀取到 PageCache 中。為了在大規(guī)模高并發(fā)場景下實(shí)現(xiàn)實(shí)現(xiàn)低延遲、高吞吐的目標(biāo)，RocketMQ 消息隊列的存儲模塊主要采用如下兩種方案。

「Mmap + PageCache 的消息并發(fā)讀寫方案」：在該方案中，消息的讀寫流程都會經(jīng)過 PageCache。在多線程并發(fā)讀寫的場景下，PageCache 不可避免會有鎖的問題，尤其是在維護(hù) PageCache 一致性時，系統(tǒng)回刷臟頁時磁盤壓力較高，會導(dǎo)致出現(xiàn)毛刺現(xiàn)象。

「堆外內(nèi)存池化技術(shù) + PageCache 的消息讀寫分離方案」：消息寫入時候?qū)懼?RocketMQ 啟動時創(chuàng)建的堆外內(nèi)存塊（DirectByteBuffer）中，同時消息從 PageCache 中讀取。這樣，消息讀寫分離使得整體流程并發(fā)性更好，有效降低時延，同時利用堆外內(nèi)存池減少了用戶態(tài)與內(nèi)核態(tài)的切換開銷。

PageCache 在 RocketMQ 消息隊列的存儲層扮演著舉足輕重的作用，一旦系統(tǒng)的 PageCache 出現(xiàn)問題（如緩存回收、一致性和缺頁中斷等問題），都會對消息收發(fā)的主要流程造成嚴(yán)重的影響。

openEuler 系統(tǒng)在緩存回收效率方面的優(yōu)化

為了防止 PageCache 申請過多（默認(rèn)無限制）將可靠內(nèi)存耗盡，需要對 PageCache 的總量及使用可靠內(nèi)存總量進(jìn)行限制。相對于 CentOS 系統(tǒng)內(nèi)核無法對未超出 node 節(jié)點(diǎn)內(nèi)存資源的 PageCache 進(jìn)行及時回收，openEuler 針對 PageCache 的回收增加了相關(guān)的系統(tǒng)內(nèi)核參數(shù)，并為限制 PageCache 使用量的功能提供若干 proc 接口，接口定義在/proc/sys/vm/下，用來控制 PageCache 的使用量，具體如下：

「cache_reclaim_enable」：表示 PageCache 限制的功能的使能開關(guān)；

「cache_reclaim_s」：表示定期觸發(fā) cache 回收的時間，以秒為單位。系統(tǒng)會根據(jù)當(dāng)前 online 的 cpu 個數(shù)來創(chuàng)建工作隊列，如果有 n 個 cpu 則創(chuàng)建 n 個工作隊列，每個工作隊列每隔 cache_reclaim_s 秒進(jìn)行一次回收。該參數(shù)與 cpu 上下線功能兼容，如果 cpu offline，則會減少工作隊列個數(shù)；反之，cpu online 則會增加工作隊列個數(shù)。

「cache_reclaim_weight」：表示每次回收的權(quán)值，內(nèi)核每個 CPU 每次期望回收 32 * cache_reclaim_weight 個 page。該權(quán)值同時作用于 page 上限觸發(fā)的回收和定期 pageCache 回收；

RocketMQ on openEuler 方案在生產(chǎn)環(huán)境中的驗(yàn)證

為解決遇到的 OOM 問題，我們針對獨(dú)享集群所在機(jī)器進(jìn)行了操作系統(tǒng)內(nèi)核版本的升級，更新至最新的 BC-Linux for Euler 21.10 版本（BC-Linux for Euler 是移動云操作系統(tǒng)團(tuán)隊以 openEuler 社區(qū)操作系統(tǒng)為基礎(chǔ)，借助開源社區(qū)的開放優(yōu)勢，通過定制化方式研發(fā)的企業(yè)級 Linux 操作系統(tǒng)）。更新系統(tǒng)后，采用兩種消息體（1Kb 和 4Kb）分別對同樣的測試環(huán)境進(jìn)行長時間的壓測。

測試場景 1

測試消息大小 1Kb 消息收發(fā)性能及長時間壓測穩(wěn)定性，測試中，獨(dú)享集群能夠達(dá)到收發(fā)消息總和 TPS 為 2w+TPS（其中發(fā)送消息 1w+TPS，消費(fèi)消息 1w+TPS）。消息生產(chǎn)和消費(fèi)的速度規(guī)律，如下圖所示：

從圖中可見在消息體大小為 1Kb 的消息時，消息生產(chǎn)和消費(fèi)速度在長時間壓測下沒有抖動，TPS 保持平穩(wěn)，整個壓測時間服務(wù)正常。

測試場景 2

測試消息大小 4Kb 消息收發(fā)性能及長時間壓測穩(wěn)定性，測試中，集群能夠達(dá)到收發(fā)消息總和 TPS 為 1.4w+ TPS（其中發(fā)送消息 0.7w+TPS，消費(fèi)消息 0.7w+TPS）。消息生產(chǎn)和消費(fèi)的速度規(guī)律，如下圖所示：

從圖中可見在消息體大小為 4Kb 的消息時，消息生產(chǎn)和消費(fèi)速度長時間壓測沒有抖動，TPS 保持平穩(wěn)，整個壓測時間服務(wù)正常。

總結(jié)

移動云 RocketMQ 消息隊列的獨(dú)享實(shí)例在 22 年已完成了云原生化的完全升級，特別適合云原生、Serverless 化架構(gòu)和大數(shù)據(jù)流計算的技術(shù)演進(jìn)與相關(guān)應(yīng)用場景。目前，RocketMQ on openEuler 的解決方案已在廣州 3 AZ2、呼和浩特、北京、杭州等多個資源池上線且完成了部分存量服務(wù)器的遷移與改造升級。后續(xù)，移動云 RocketMQ 消息隊列并將不斷提升服務(wù)質(zhì)量，為廣大客戶創(chuàng)造更多的價值。歡迎大家多多關(guān)注。

審核編輯：湯梓紅