Apache Pulsar在小紅書在線場景下的探索與實(shí)踐

2024-10-23 20:09:47

本文結(jié)合消息隊(duì)列進(jìn)行選型介紹，就 Pulsar 和 RocketMQ 的特性作對比，介紹 Pulsar 在小紅書在線消息隊(duì)列的場景下如何落地，以及企業(yè)可以獲得哪些實(shí)際收益。同時，文章結(jié)合小紅書消息隊(duì)列的實(shí)際情況、經(jīng)驗(yàn)進(jìn)行了整理和數(shù)據(jù)匯總。

01 背景

1.1 消息隊(duì)列的定義

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

消息隊(duì)列核心組成：

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

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

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

1.2 行業(yè)趨勢

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

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

02 現(xiàn)狀分析

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

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

當(dāng)前形態(tài)：

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

2.2 存在問題

03、演進(jìn)路線

3.1 選型決策：Pulsar 或 RocketMQ5.x

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

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

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

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

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

RocketMQ 2 副本和 Pulsar 3 副本消耗資源都是：32核+128GB內(nèi)存+16TB磁盤，但是 Pulsar 可以借助多盤特性、用更廉價的盤拼出更高的性能：
基于新架構(gòu)，設(shè)計更合理的部署架構(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利用率提升：提升資源利用率，通過實(shí)現(xiàn)副本流量對等，有效規(guī)避RocketMQ Slave 副本資源浪費(fèi)的情況，可降低 21.5% 的 CPU 資源成本。

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

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

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

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

核心邏輯：

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

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

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

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

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

縮容平滑：做到無損，不改變順序讀寫，更加優(yōu)雅；
計算層（Broker 無狀態(tài)）：縮容后，自動卸載流量，流量自動均衡到其他節(jié)點(diǎn)；
存儲層（BookKeeper 有狀態(tài)）：縮容后，無需要干預(yù)，流量自動均衡（策略有：非緊急的縮容，節(jié)點(diǎn)直接隔離待數(shù)據(jù)失效+緊急下線數(shù)據(jù)遷移）。

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

Pulsar 架構(gòu)圖

RocketMQ 5.0 架構(gòu)圖

3.2 演進(jìn)方向

核心名詞解釋：

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

設(shè)計目標(biāo)：

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

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

3.3 客戶端標(biāo)準(zhǔn)化

客戶端標(biāo)準(zhǔn)化讓客戶端接入都收斂，實(shí)現(xiàn)標(biāo)準(zhǔn)化接入：

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

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

Pulsar 遷移路徑：

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

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

整體架構(gòu)設(shè)計點(diǎn)：

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

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

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

05 總結(jié)與展望

5.1 階段性總結(jié)

演進(jìn)計劃當(dāng)前進(jìn)度：

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

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

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

5.2 展望

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

Pulsar 落地：

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

客戶端標(biāo)準(zhǔn)化推進(jìn)：
通過直接客戶端改造和間接標(biāo)準(zhǔn)化（框架底層代碼橋接，間接實(shí)現(xiàn)標(biāo)準(zhǔn)化）兩種方式共同推進(jìn)客戶段標(biāo)準(zhǔn)化的覆蓋；
同時也逐步擴(kuò)大 Pulsar 遷移范圍；
最終實(shí)現(xiàn)客戶端標(biāo)準(zhǔn)化的 100% 覆蓋。
穩(wěn)定性建設(shè)：
快速止損預(yù)案應(yīng)對（共同的目標(biāo)）：去應(yīng)對未知場景的 Bug，快速止損，這不僅是未來引擎，也是當(dāng)前引擎所要具備的能力；
Monitor 全鏈路探針：端到端的探針，核心鏈路全覆蓋，及時發(fā)現(xiàn)故障節(jié)點(diǎn)。