01 背景

1.1 消息隊列的定義

消息隊列（簡稱：MQ）是分布式架構(gòu)中的重要組件，提供異步通信的基礎(chǔ)能力，通過應用解耦降低系統(tǒng)復雜度，提升系統(tǒng)可用性和可擴展性。

消息隊列核心組成：

• Producer：生產(chǎn)者，負責產(chǎn)生和發(fā)送消息到 Broker；
• Consumer：消費者，負責從 Broker 中獲取消息，并進行相應處理；
• Queue：保存消息的數(shù)據(jù)結(jié)構(gòu)，提供消息隊列先進先出特性；
• Message：實際數(shù)據(jù)內(nèi)容，包含了生產(chǎn)者發(fā)送給消費者的信息；
• Broker：消息引擎，負責消息存儲、確認、重試等。

消息隊列是不同應用之間異步通信的中間產(chǎn)品，其本質(zhì)特征：

• 解耦：解除上、下游系統(tǒng)的依賴，達到解耦目的；
• 削峰：通過使用消息隊列作為緩沖，將多余的請求存放在隊列中，避免系統(tǒng)因瞬時高并發(fā)請求而崩潰。當系統(tǒng)處理能力恢復時，再從隊列中取出請求進行處理；
• 異步：解耦合+轉(zhuǎn)存，消息的處理結(jié)果不需要被即時依賴，上、下游系統(tǒng)可以異步進行，而異步本身直接帶來了緩沖、削峰、最終一致性等能力。

1.2 行業(yè)趨勢

行業(yè)公司消息隊列選型：

業(yè)界選型上，Kafka 是離線大數(shù)據(jù)重要組成，在線消息因為豐富的業(yè)務功能訴求（事務消息、延遲消息、死信消息等）選擇 RocketMQ 或 Pulsar。

02 現(xiàn)狀分析

2.1 現(xiàn)狀及規(guī)模

Red Events MQ 基于 DDMQ 在小紅書落地的一套 Discovery + Proxy + RocketMQ 引擎的架構(gòu)，其架構(gòu)如下：

當前形態(tài)：

1. 管控平臺：Topic 在管控平臺創(chuàng)建和維護；
2. 服務發(fā)現(xiàn)：服務發(fā)現(xiàn)同步管控平臺信息，對 SDK 提供元數(shù)據(jù)信息（集群信息）；
3. Proxy：屏蔽用戶對底層MQ的依賴，提供數(shù)據(jù)服務；
4. Client SDK：客戶端，由于客戶端場景覆蓋不足，導致各類客戶端、各種連接方式共存，數(shù)據(jù)平臺類的接入均覆蓋不到。

2.2 存在問題

03、演進路線

3.1  選型決策：Pulsar 或 RocketMQ5.x

RocketMQ 和 Pulsar 都是 Apache 的頂級項目，同樣優(yōu)秀；但是如下幾點還是讓我們決策 Pulsar 成為未來我們新的架構(gòu)引擎：

Pulsar 獨有的優(yōu)勢：

匯總成本收益：當前流量情況下，成本降低 48%；在未來 10 倍增長量的情況下，成本會持續(xù)降低。

在小紅書當前場景，當前集群和流量規(guī)模情況下（RocketMQ 采用了 2 副本、承載同等流量的情況），如果使用 Pulsar 能帶來如下收益：

1、存儲成本下降：存儲成本更低，Pulsar 多盤部署架構(gòu)，部署架構(gòu)實現(xiàn)讓存儲成本下降 27%.

• RocketMQ 2 副本和 Pulsar 3 副本消耗資源都是：32核+128GB內(nèi)存+16TB磁盤，但是 Pulsar 可以借助多盤特性、用更廉價的盤拼出更高的性能：
• 基于新架構(gòu)，設計更合理的部署架構(gòu)，拿到的收益.

• [前提] CPU、內(nèi)存、存儲容量保持不變的前提，拿到了其他的收益；

• [收益] 磁盤總帶寬上升：經(jīng)過多盤的拼接，磁盤帶寬從350MB/s上升600MB/s，提升71%；

• [收益] 成本下降：從現(xiàn)有架構(gòu)的 RocketMQ2 副本（Master/Slave Broker）到 Pulsar3 副本（1*Broker+3*BookKeeper），成本下降27%.

2、CPU利用率提升：提升資源利用率，通過實現(xiàn)副本流量對等，有效規(guī)避RocketMQ Slave 副本資源浪費的情況，可降低 21.5% 的 CPU 資源成本。

• 追趕讀（Catch-up Reads）：消費者落后，在線業(yè)務場景很少，RocketMQ 的 Master/Slave 都會承載流量，線上追趕讀的峰值流量：流量占比：3.5%；
• 追尾讀（Tailing Reads）：寫完立刻讀，在線業(yè)務此場景偏多，RocketMQ此架構(gòu)只有 Master 才會承載，線上追尾讀的峰值流量：流量占比：96.5%，此場景下存在 CPU 的資源浪費：

• Master 節(jié)點：16 核 CPU 峰值使用率高達 50%，計算資源主要消耗在 Client數(shù)據(jù)的寫、讀、Slave 的同步；
• Slave 節(jié)點：16 核 CPU 峰值使用率只有 7%，計算資源主要消耗在從 Master 拉取數(shù)據(jù)；

• 按 RocketMQ 的 Master 節(jié)點的 CPU 使用率 50% 滿足集群擴容需求，但是 Slave 節(jié)點的 CPU 利用率確很低，Pulsar 可實現(xiàn)副本完全對等，如果換成 Pulsar，可提升這 43% 的 CPU 使用率，在縮容降本情況下，可降低 21.5% 的成本。

3、彈性伸縮、按量計費：基于這個特性， 讓成本降低30%

• 核心邏輯：

• 配額：為了滿足指定指定 TPS 需要提供的資源，當前集群評估水位的標準是峰值 TPS；
• 實際使用量：用戶實際使用的資源，用平均 TPS 代替；
• 冗余率：（配額 - 實際使用量)  /  配額，得到資源冗余率，這部分冗余資源就是彈性伸縮架構(gòu)理論上可以獲得的最大收益；

• 小紅書在線消息現(xiàn)狀，彈性伸縮可得最大收益：按 2 小時調(diào)度一次，可節(jié)約 30% 左右的資源用量。

4、運維友好：云化部署、彈性伸縮更加平滑。

• 云化部署：借助 Ones/K8s 云部署優(yōu)勢，減少重復的運維能力建設；
• 擴容平滑：無需做擴容分區(qū)、遷移分區(qū)等運維操作；

• 計算層（Broker 無狀態(tài)）：擴容后，無需運維，流量自動均衡；
• 存儲層（BookKeeper 有狀態(tài)）：擴容后，無需要干預，新 Ledger 創(chuàng)建后，流量自動覆蓋新節(jié)點；

• 縮容平滑：做到無損，不改變順序讀寫，更加優(yōu)雅；

• 計算層（Broker 無狀態(tài)）：縮容后，自動卸載流量，流量自動均衡到其他節(jié)點；

• 存儲層（BookKeeper 有狀態(tài)）：縮容后，無需要干預，流量自動均衡（策略有：非緊急的縮容，節(jié)點直接隔離待數(shù)據(jù)失效+緊急下線數(shù)據(jù)遷移）。

Pulsar VS RocketMQ 5.0核心能力（綠色塊：代表優(yōu)勢； 橘色塊：代表劣勢）

Pulsar 架構(gòu)圖

RocketMQ 5.0 架構(gòu)圖

3.2 演進方向

核心名詞解釋：

• 設計思想：Red Events（事件總線）本質(zhì)上是一個 MQ 代理，目的是對用戶屏蔽底層 MQ 的實現(xiàn)，提供統(tǒng)一的接入方式、集群的運維和治理；
• Topic：是數(shù)據(jù)發(fā)布和訂閱的基本單位，它代表了相同類型的消息流；
• Event：是對 Topic 的抽象，提供了集群和 Topic 的綁定關(guān)系，可動態(tài)調(diào)整，更便于用戶使用；
• 元數(shù)據(jù)：Topic 的元數(shù)據(jù)服務，供 Events Client 感知集群等信息；
• Events Client：標準化的客戶端，提供統(tǒng)一的接入方式，用戶發(fā)送、消費消息的工具；
• Proxy：MQ 代理，提供統(tǒng)一的集群運維和治理；
• Pulsar Clusters：MQ 的引擎，一套存算分離的云原生架構(gòu)。

設計目標：

1. Events 客戶端標準化、可觀測、功能輕量：作為統(tǒng)一接入的客戶端，各類語言（http兜底）客戶端、各類場景（flink等）全量覆蓋，讓用戶接入 MQ 更加穩(wěn)定、可控
2. Events Proxy：MQ 的代理，屏蔽用戶對底層 MQ 引擎選擇，只需要關(guān)注核心問題：RT/吞吐/功能/成本
3. MQ 新引擎的方向：替換原有的 RocketMQ4.x，構(gòu)建一套存算分離的云原生架構(gòu)，新引擎做到 100% 流量全部覆蓋

通過客戶端標準化和平滑遷移這兩種手段，讓 Pulsar 在小紅書落地成為可能。

3.3 客戶端標準化

客戶端標準化讓客戶端接入都收斂，實現(xiàn)標準化接入：

• 用戶客戶端改造，使用標準化接入方式 EventClient；
• 客戶端改造過程中觸發(fā)自動化灰度切流；
• 客戶端改造完成，觀察業(yè)務指標是否符合預期。及時發(fā)現(xiàn)并解決客戶端改造過程中的問題。

3.4 架構(gòu)升級到Pulsar

Pulsar 遷移路徑：

• 按優(yōu)遷移、平滑無感：按業(yè)務優(yōu)先級，從低優(yōu)到高優(yōu)逐步遷移，旨在平滑遷移，用戶無感；
• Pulsar 遷移最終覆蓋到100%：依賴客戶端標準化的推動進度，首先推動 11% 上下游均標準化的部分，之后隨標準化橋接推進，共同推進到 71%，最終實現(xiàn)Pulsar 100% 的覆蓋；
• 遷移同時對資源使用率的治理：Pulsar 遷移過程也將逐步實現(xiàn)資源使用率的提升，從觀察期 30%，最終提升資源使用率到 50%.

04 在線消息規(guī)劃設計

整體架構(gòu)設計點：

• 以 Pulsar 為底座，構(gòu)建一個存算分離的云原生架構(gòu)；
• 構(gòu)建更多特色功能：跨云多活、實時隊列、延遲隊列、分層存儲能力、彈性伸縮及彈性計費的功能，分階段讓用戶享受到架構(gòu)的紅利。

整個架構(gòu)的設計維度：

• 創(chuàng)建 Topic 入口統(tǒng)一：所有 Topic /消費組都在管控平臺創(chuàng)建；
• Client 所有場景覆蓋：Events 客戶端標準化、可觀測、功能輕量：各類語言（http兜底）客戶端、各類場景（flink等）全量覆蓋；
• Events 客戶端標準化、可觀測、功能輕量：操作均通過 Events Proxy 做數(shù)據(jù)通信；
• Events Proxy：MQ 的代理，屏蔽用戶對底層 MQ 引擎選擇，只需要關(guān)注核心問題：RT/吞吐/功能/成本；
• MQ 全鏈路能力對齊：支持云原生，容器化、彈性擴縮、具備彈性計費能力（按量計費）、支持各維度多活。

05 總結(jié)與展望

5.1 階段性總結(jié)

演進計劃當前進度：

• 新架構(gòu)（Pulsar）流量占比11.8%.

當前已經(jīng)拿到的收益：

• 成本：降低42%（主要是存儲成本下降，使用了同容量、多塊更廉價的盤）；
• 資源利用率（CPU使用率）：34%（主62%、從7%）提升到60%；
• RT耗時（客戶端E2E ）：max(P99) 20.2ms 降到 5.7ms；
• 人工運維量：當前都部署在云上，借助云調(diào)度+自動卸載+注冊，降低運維工作。

5.2 展望

長遠規(guī)劃：完成 Pulsar 規(guī)劃，制定客戶端標準化、平滑遷移計劃，同時做到穩(wěn)定性建設。

1. Pulsar 落地：

1. 繼續(xù)完善功能完備性、生產(chǎn)穩(wěn)定性、可觀測 、運維能力；
2. 按照集群重保等級逐一遷移到 Pulsar；
3. 新Topic收口：新申請 Topic 直接創(chuàng)建在 Pulsar；
4. 100% 平滑遷移到 Pulsar，下線 RocketMQ.

2. 客戶端標準化推進：

3. 通過直接客戶端改造和間接標準化（框架底層代碼橋接，間接實現(xiàn)標準化）兩種方式共同推進客戶段標準化的覆蓋；

4. 同時也逐步擴大 Pulsar 遷移范圍；

5. 最終實現(xiàn)客戶端標準化的 100% 覆蓋。

6. 穩(wěn)定性建設：

7. 快速止損預案應對（共同的目標）：去應對未知場景的 Bug，快速止損，這不僅是未來引擎，也是當前引擎所要具備的能力；

8. Monitor 全鏈路探針：端到端的探針，核心鏈路全覆蓋，及時發(fā)現(xiàn)故障節(jié)點。

06 作者簡介

• 諾林
  在線消息隊列方向負責人，開源社區(qū)角色：Apache BookKeeper Committer

• 無桀
  在線消息隊列研發(fā)，開源社區(qū)角色：Apache Pulsar Contributer

• 月初
  在線消息隊列研發(fā)，開源社區(qū)角色：Apache Pulsar Committer

07 參考文獻

1. Apache Pulsar? documentation：https://pulsar.apache.org/docs/
2. Apache RocketMQ documentation：https://rocketmq.apache.org/docs/
3. Pulsar Meetup 北京 2024：https://mp.weixin.qq.com/s/kj6nf_iMc7r8rzc5XXRdUg