RocketMQ on openEuler，是一種将 RocketMQ 消息中間件通過容器化的方式部署在 openEuler 作業系統上運作，借助 openEuler 系統對于 OS 緩存回收效率增強的核心特性，提升消息中間件在面向超大規模高并發、高吞吐量、低延遲場景下穩定性和可靠性的軟體解決方案。
RocketMQ 消息隊列在穩壓測試中遇到的 OOM 問題
移動雲 RocketMQ 消息隊列産品正式上線前，通過壓測工具，建立多組生産者/消費者程序對 RocketMQ 獨享叢集做多輪性能和穩定性的壓力測試。
測試環境
壓測結果
在某次持續長時間的壓測過程中，發現消息收發吞吐，在一段時間内的某一時刻會出現大幅度 TPS（生産/消費）抖動下降的現象，并且是周期性的。
移動雲 RocketMQ 消息隊列一直都比較穩定運作，為何在高并發的壓測下也會出現 TPS 的抖動？我們初步懷疑是 CPU 負載或者 RocketMQ Broker 元件 GC 頻率過高導緻，但通過檢視 CPU 負載和 JVM GC 頻率并未發現任何異常。最終，經過排查發現是由于 Broker Pod 程序中的 buff/cache 在持續長時間壓測下不斷增加，系統無法及時有效回收，導緻 Pod 中的運作程序占用記憶體空間超出預先設定的 Limit 限制，觸發了 OOM Killer 機制重新開機了 Broker Pod。
RocketMQ on openEuler—解決大規模高并發場景下提升穩定性的新選擇
為何在持續高并發下進行消息收發會導緻系統的 buff/cache 的持續增加？通過翻閱作業系統手冊，可知 buff/cache 主要展現在系統的 PageCache 上。
PageCache 在 RocketMQ 消息存儲中的重要作用
PageCache 也叫頁緩沖或檔案緩沖，在 linux 讀寫檔案時，它用于緩存檔案的邏輯内容，進而加快對磁盤上映像和資料的通路。
上圖中，紅色部分即為，PageCache。可見 PageCache 的本質是由 Linux 核心管理的記憶體區域。平時我們寫的各種程式，通過 mmap 及 buffered I/O 将檔案讀取到記憶體空間實際上都是讀取到 PageCache 中。為了在大規模高并發場景下實作實作低延遲、高吞吐的目标，RocketMQ 消息隊列的存儲子產品主要采用如下兩種方案。
- 「Mmap + PageCache 的消息并發讀寫方案」：在該方案中，消息的讀寫流程都會經過 PageCache。在多線程并發讀寫的場景下，PageCache 不可避免會有鎖的問題，尤其是在維護 PageCache 一緻性時，系統回刷髒頁時磁盤壓力較高，會導緻出現毛刺現象。
- 「堆外記憶體池化技術 + PageCache 的消息讀寫分離方案」：消息寫入時候寫至 RocketMQ 啟動時建立的堆外記憶體塊（DirectByteBuffer）中，同時消息從 PageCache 中讀取。這樣，消息讀寫分離使得整體流程并發性更好，有效降低延遲時間，同時利用堆外記憶體池減少了使用者态與核心态的切換開銷。
PageCache 在 RocketMQ 消息隊列的存儲層扮演着舉足輕重的作用，一旦系統的 PageCache 出現問題（如緩存回收、一緻性和缺頁中斷等問題），都會對消息收發的主要流程造成嚴重的影響。
openEuler 系統在緩存回收效率方面的優化
為了防止 PageCache 申請過多（預設無限制）将可靠記憶體耗盡，需要對 PageCache 的總量及使用可靠記憶體總量進行限制。相對于 CentOS 系統核心無法對未超出 node 節點記憶體資源的 PageCache 進行及時回收，openEuler 針對 PageCache 的回收增加了相關的系統核心參數，并為限制 PageCache 使用量的功能提供若幹 proc 接口，接口定義在/proc/sys/vm/下，用來控制 PageCache 的使用量，具體如下：
- 「cache_reclaim_enable」：表示 PageCache 限制的功能的使能開關；
- 「cache_reclaim_s」：表示定期觸發 cache 回收的時間，以秒為機關。系統會根據目前 online 的 cpu 個數來建立工作隊列，如果有 n 個 cpu 則建立 n 個工作隊列，每個工作隊列每隔 cache_reclaim_s 秒進行一次回收。該參數與 cpu 上下線功能相容，如果 cpu offline，則會減少工作隊列個數；反之，cpu online 則會增加工作隊列個數。
- 「cache_reclaim_weight」：表示每次回收的權值，核心每個 CPU 每次期望回收 32 * cache_reclaim_weight 個 page。該權值同時作用于 page 上限觸發的回收和定期 pageCache 回收；
RocketMQ on openEuler 方案在生産環境中的驗證
為解決遇到的 OOM 問題，我們針對獨享叢集所在機器進行了作業系統核心版本的更新，更新至最新的 BC-Linux for Euler 21.10 版本（BC-Linux for Euler 是移動雲作業系統團隊以 openEuler 社群作業系統為基礎，借助開源社群的開放優勢，通過定制化方式研發的企業級 Linux 作業系統）。更新系統後，采用兩種消息體（1Kb 和 4Kb）分别對同樣的測試環境進行長時間的壓測。
測試場景 1
測試消息大小 1Kb 消息收發性能及長時間壓測穩定性，測試中，獨享叢集能夠達到收發消息總和 TPS 為 2w+TPS（其中發送消息 1w+TPS，消費消息 1w+TPS）。消息生産和消費的速度規律，如下圖所示：
從圖中可見在消息體大小為 1Kb 的消息時，消息生産和消費速度在長時間壓測下沒有抖動，TPS 保持平穩，整個壓測時間服務正常。
測試場景 2
測試消息大小 4Kb 消息收發性能及長時間壓測穩定性，測試中，叢集能夠達到收發消息總和 TPS 為 1.4w+ TPS（其中發送消息 0.7w+TPS，消費消息 0.7w+TPS）。消息生産和消費的速度規律，如下圖所示：
從圖中可見在消息體大小為 4Kb 的消息時，消息生産和消費速度長時間壓測沒有抖動，TPS 保持平穩，整個壓測時間服務正常。
總結
移動雲 RocketMQ 消息隊列的獨享執行個體在 22 年已完成了雲原生化的完全更新，特别适合雲原生、Serverless 化架構和大資料流計算的技術演進與相關應用場景。目前，RocketMQ on openEuler 的解決方案已在廣州 3 AZ2、呼和浩特、北京、杭州等多個資源池上線且完成了部分存量伺服器的遷移與改造更新。後續，移動雲 RocketMQ 消息隊列并将不斷提升服務品質，為廣大客戶創造更多的價值。歡迎大家多多關注。