01 背景

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

消息隊(duì)列（簡(jiǎn)稱：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é)消息存儲(chǔ)、確認(rèn)、重試等。

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

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

1.2 行業(yè)趨勢(shì)

行業(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)：

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

2.2 存在問題

03、演進(jìn)路線

3.1  選型決策：Pulsar 或 RocketMQ5.x

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

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

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

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

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

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

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

• [收益] 磁盤總帶寬上升：經(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)副本流量對(duì)等，有效規(guī)避RocketMQ Slave 副本資源浪費(fèi)的情況，可降低 21.5% 的 CPU 資源成本。

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

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

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

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

• 核心邏輯：

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

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

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

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

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

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

• 計(jì)算層（Broker 無(wú)狀態(tài)）：縮容后，自動(dòng)卸載流量，流量自動(dòng)均衡到其他節(jié)點(diǎn)；

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

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

Pulsar 架構(gòu)圖

RocketMQ 5.0 架構(gòu)圖

3.2 演進(jìn)方向

核心名詞解釋：

• 設(shè)計(jì)思想：Red Events（事件總線）本質(zhì)上是一個(gè) MQ 代理，目的是對(duì)用戶屏蔽底層 MQ 的實(shí)現(xiàn)，提供統(tǒng)一的接入方式、集群的運(yùn)維和治理；
• Topic：是數(shù)據(jù)發(fā)布和訂閱的基本單位，它代表了相同類型的消息流；
• Event：是對(duì) Topic 的抽象，提供了集群和 Topic 的綁定關(guān)系，可動(dòng)態(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è)計(jì)目標(biāo)：

1. Events 客戶端標(biāo)準(zhǔn)化、可觀測(cè)、功能輕量：作為統(tǒng)一接入的客戶端，各類語(yǔ)言（http兜底）客戶端、各類場(chǎng)景（flink等）全量覆蓋，讓用戶接入 MQ 更加穩(wěn)定、可控
2. Events Proxy：MQ 的代理，屏蔽用戶對(duì)底層 MQ 引擎選擇，只需要關(guān)注核心問題：RT/吞吐/功能/成本
3. 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ā)自動(dòng)化灰度切流；
• 客戶端改造完成，觀察業(yè)務(wù)指標(biāo)是否符合預(yù)期。及時(shí)發(fā)現(xiàn)并解決客戶端改造過程中的問題。

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

Pulsar 遷移路徑：

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

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

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

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

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

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

05 總結(jié)與展望

5.1 階段性總結(jié)

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

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

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

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

5.2 展望

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

1. Pulsar 落地：

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

2. 客戶端標(biāo)準(zhǔn)化推進(jìn)：

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

4. 同時(shí)也逐步擴(kuò)大 Pulsar 遷移范圍；

5. 最終實(shí)現(xiàn)客戶端標(biāo)準(zhǔn)化的 100% 覆蓋。

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

7. 快速止損預(yù)案應(yīng)對(duì)（共同的目標(biāo)）：去應(yīng)對(duì)未知場(chǎng)景的 Bug，快速止損，這不僅是未來(lái)引擎，也是當(dāng)前引擎所要具備的能力；

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

06 作者簡(jiǎn)介

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

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

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

07 參考文獻(xiàn)

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