Apache Pulsar在小紅書在線場景下的探索與實踐
01 背景
1.1 消息隊列的定義
消息隊列（簡稱：MQ）是分布式架構中的重要組件，提供異步通信的基礎能力，通過應用解耦降低系統復雜度，提升系統可用性和可擴展性。
消息隊列核心組成：
- Producer：生產者，負責產生和發送消息到 Broker；
- Consumer：消費者，負責從 Broker 中獲取消息，并進行相應處理；
- Queue：保存消息的數據結構，提供消息隊列先進先出特性；
- Message：實際數據內容，包含了生產者發送給消費者的信息；
- Broker：消息引擎，負責消息存儲、確認、重試等。
消息隊列是不同應用之間異步通信的中間產品，其本質特征：
- 解耦：解除上、下游系統的依賴，達到解耦目的；
- 削峰：通過使用消息隊列作為緩沖，將多余的請求存放在隊列中，避免系統因瞬時高并發請求而崩潰。當系統處理能力恢復時，再從隊列中取出請求進行處理；
- 異步：解耦合+轉存，消息的處理結果不需要被即時依賴，上、下游系統可以異步進行，而異步本身直接帶來了緩沖、削峰、最終一致性等能力。
1.2 行業趨勢
行業公司消息隊列選型：
業界選型上，Kafka 是離線大數據重要組成，在線消息因為豐富的業務功能訴求（事務消息、延遲消息、死信消息等）選擇 RocketMQ 或 Pulsar。
02 現狀分析
2.1 現狀及規模
Red Events MQ 基于 DDMQ 在小紅書落地的一套 Discovery + Proxy + RocketMQ 引擎的架構，其架構如下：
當前形態：
- 管控平臺：Topic 在管控平臺創建和維護；
- 服務發現：服務發現同步管控平臺信息，對 SDK 提供元數據信息（集群信息）；
- Proxy：屏蔽用戶對底層MQ的依賴，提供數據服務；
- Client SDK：客戶端，由于客戶端場景覆蓋不足，導致各類客戶端、各種連接方式共存，數據平臺類的接入均覆蓋不到。
2.2 存在問題
03、演進路線
3.1 選型決策：Pulsar 或 RocketMQ5.x
RocketMQ 和 Pulsar 都是 Apache 的頂級項目，同樣優秀；但是如下幾點還是讓我們決策 Pulsar 成為未來我們新的架構引擎：
Pulsar 獨有的優勢：
匯總成本收益：當前流量情況下，成本降低 48%；在未來 10 倍增長量的情況下，成本會持續降低。
在小紅書當前場景，當前集群和流量規模情況下（RocketMQ 采用了 2 副本、承載同等流量的情況），如果使用 Pulsar 能帶來如下收益：
1、存儲成本下降：存儲成本更低，Pulsar 多盤部署架構，部署架構實現讓存儲成本下降 27%.
- RocketMQ 2 副本和 Pulsar 3 副本消耗資源都是：32核+128GB內存+16TB磁盤，但是 Pulsar 可以借助多盤特性、用更廉價的盤拼出更高的性能：
- 基于新架構，設計更合理的部署架構，拿到的收益.
[前提] CPU、內存、存儲容量保持不變的前提，拿到了其他的收益；
[收益] 磁盤總帶寬上升：經過多盤的拼接，磁盤帶寬從350MB/s上升600MB/s，提升71%；
[收益] 成本下降：從現有架構的 RocketMQ2 副本（Master/Slave Broker）到 Pulsar3 副本（1*Broker+3*BookKeeper），成本下降27%.
2、CPU利用率提升：提升資源利用率，通過實現副本流量對等，有效規避RocketMQ Slave 副本資源浪費的情況，可降低 21.5% 的 CPU 資源成本。
- 追趕讀（Catch-up Reads）：消費者落后，在線業務場景很少，RocketMQ 的 Master/Slave 都會承載流量，線上追趕讀的峰值流量：流量占比：3.5%；
- 追尾讀（Tailing Reads）：寫完立刻讀，在線業務此場景偏多，RocketMQ此架構只有 Master 才會承載，線上追尾讀的峰值流量：流量占比：96.5%，此場景下存在 CPU 的資源浪費：
- Master 節點：16 核 CPU 峰值使用率高達 50%，計算資源主要消耗在 Client數據的寫、讀、Slave 的同步；
- Slave 節點：16 核 CPU 峰值使用率只有 7%，計算資源主要消耗在從 Master 拉取數據；
- 按 RocketMQ 的 Master 節點的 CPU 使用率 50% 滿足集群擴容需求，但是 Slave 節點的 CPU 利用率確很低，Pulsar 可實現副本完全對等，如果換成 Pulsar，可提升這 43% 的 CPU 使用率，在縮容降本情況下，可降低 21.5% 的成本。
3、彈性伸縮、按量計費：基于這個特性， 讓成本降低30%
- 核心邏輯：
- 配額：為了滿足指定指定 TPS 需要提供的資源，當前集群評估水位的標準是峰值 TPS；
- 實際使用量：用戶實際使用的資源，用平均 TPS 代替；
- 冗余率：（配額 - 實際使用量) / 配額，得到資源冗余率，這部分冗余資源就是彈性伸縮架構理論上可以獲得的最大收益；
- 小紅書在線消息現狀，彈性伸縮可得最大收益：按 2 小時調度一次，可節約 30% 左右的資源用量。
4、運維友好：云化部署、彈性伸縮更加平滑。
- 云化部署：借助 Ones/K8s 云部署優勢，減少重復的運維能力建設；
- 擴容平滑：無需做擴容分區、遷移分區等運維操作；
- 計算層（Broker 無狀態）：擴容后，無需運維，流量自動均衡；
- 存儲層（BookKeeper 有狀態）：擴容后，無需要干預，新 Ledger 創建后，流量自動覆蓋新節點；
- 縮容平滑：做到無損，不改變順序讀寫，更加優雅；
計算層（Broker 無狀態）：縮容后，自動卸載流量，流量自動均衡到其他節點；
存儲層（BookKeeper 有狀態）：縮容后，無需要干預，流量自動均衡（策略有：非緊急的縮容，節點直接隔離待數據失效+緊急下線數據遷移）。
Pulsar VS RocketMQ 5.0核心能力（綠色塊：代表優勢； 橘色塊：代表劣勢）
Pulsar 架構圖
RocketMQ 5.0 架構圖
3.2 演進方向
核心名詞解釋：
- 設計思想：Red Events（事件總線）本質上是一個 MQ 代理，目的是對用戶屏蔽底層 MQ 的實現，提供統一的接入方式、集群的運維和治理；
- Topic：是數據發布和訂閱的基本單位，它代表了相同類型的消息流；
- Event：是對 Topic 的抽象，提供了集群和 Topic 的綁定關系，可動態調整，更便于用戶使用；
- 元數據：Topic 的元數據服務，供 Events Client 感知集群等信息；
- Events Client：標準化的客戶端，提供統一的接入方式，用戶發送、消費消息的工具；
- Proxy：MQ 代理，提供統一的集群運維和治理；
- Pulsar Clusters：MQ 的引擎，一套存算分離的云原生架構。
設計目標：
- Events 客戶端標準化、可觀測、功能輕量：作為統一接入的客戶端，各類語言（http兜底）客戶端、各類場景（flink等）全量覆蓋，讓用戶接入 MQ 更加穩定、可控
- Events Proxy：MQ 的代理，屏蔽用戶對底層 MQ 引擎選擇，只需要關注核心問題：RT/吞吐/功能/成本
- MQ 新引擎的方向：替換原有的 RocketMQ4.x，構建一套存算分離的云原生架構，新引擎做到 100% 流量全部覆蓋
通過客戶端標準化和平滑遷移這兩種手段，讓 Pulsar 在小紅書落地成為可能。
3.3 客戶端標準化
客戶端標準化讓客戶端接入都收斂，實現標準化接入：
- 用戶客戶端改造，使用標準化接入方式 EventClient；
- 客戶端改造過程中觸發自動化灰度切流；
- 客戶端改造完成，觀察業務指標是否符合預期。及時發現并解決客戶端改造過程中的問題。
3.4 架構升級到Pulsar
Pulsar 遷移路徑：
- 按優遷移、平滑無感：按業務優先級，從低優到高優逐步遷移，旨在平滑遷移，用戶無感；
- Pulsar 遷移最終覆蓋到100%：依賴客戶端標準化的推動進度，首先推動 11% 上下游均標準化的部分，之后隨標準化橋接推進，共同推進到 71%，最終實現Pulsar 100% 的覆蓋；
- 遷移同時對資源使用率的治理：Pulsar 遷移過程也將逐步實現資源使用率的提升，從觀察期 30%，最終提升資源使用率到 50%.
04 在線消息規劃設計
整體架構設計點：
- 以 Pulsar 為底座，構建一個存算分離的云原生架構；
- 構建更多特色功能：跨云多活、實時隊列、延遲隊列、分層存儲能力、彈性伸縮及彈性計費的功能，分階段讓用戶享受到架構的紅利。
整個架構的設計維度：
- 創建 Topic 入口統一：所有 Topic /消費組都在管控平臺創建；
- Client 所有場景覆蓋：Events 客戶端標準化、可觀測、功能輕量：各類語言（http兜底）客戶端、各類場景（flink等）全量覆蓋；
- Events 客戶端標準化、可觀測、功能輕量：操作均通過 Events Proxy 做數據通信；
- Events Proxy：MQ 的代理，屏蔽用戶對底層 MQ 引擎選擇，只需要關注核心問題：RT/吞吐/功能/成本；
- MQ 全鏈路能力對齊：支持云原生，容器化、彈性擴縮、具備彈性計費能力（按量計費）、支持各維度多活。
05 總結與展望
5.1 階段性總結
演進計劃當前進度：
- 新架構（Pulsar）流量占比11.8%.
當前已經拿到的收益：
- 成本：降低42%（主要是存儲成本下降，使用了同容量、多塊更廉價的盤）；
- 資源利用率（CPU使用率）：34%（主62%、從7%）提升到60%；
- RT耗時（客戶端E2E ）：max(P99) 20.2ms 降到 5.7ms；
- 人工運維量：當前都部署在云上，借助云調度+自動卸載+注冊，降低運維工作。
5.2 展望
長遠規劃：完成 Pulsar 規劃，制定客戶端標準化、平滑遷移計劃，同時做到穩定性建設。
- Pulsar 落地：
- 繼續完善功能完備性、生產穩定性、可觀測 、運維能力；
- 按照集群重保等級逐一遷移到 Pulsar；
- 新Topic收口：新申請 Topic 直接創建在 Pulsar；
- 100% 平滑遷移到 Pulsar，下線 RocketMQ.
- 客戶端標準化推進：
通過直接客戶端改造和間接標準化（框架底層代碼橋接，間接實現標準化）兩種方式共同推進客戶段標準化的覆蓋；
同時也逐步擴大 Pulsar 遷移范圍；
最終實現客戶端標準化的 100% 覆蓋。
穩定性建設：
快速止損預案應對（共同的目標）：去應對未知場景的 Bug，快速止損，這不僅是未來引擎，也是當前引擎所要具備的能力；
Monitor 全鏈路探針：端到端的探針，核心鏈路全覆蓋，及時發現故障節點。
06 作者簡介
- 諾林
在線消息隊列方向負責人，開源社區角色：Apache BookKeeper Committer
- 無桀
在線消息隊列研發，開源社區角色：Apache Pulsar Contributer
- 月初
在線消息隊列研發，開源社區角色：Apache Pulsar Committer
07 參考文獻
- Apache Pulsar? documentation：https://pulsar.apache.org/docs/
- Apache RocketMQ documentation：https://rocketmq.apache.org/docs/
- Pulsar Meetup 北京 2024：https://mp.weixin.qq.com/s/kj6nf_iMc7r8rzc5XXRdUg
