作者 | 諳流科技奇秋月

引 言

消息系統(tǒng)是現(xiàn)代企業(yè)數(shù)據基礎設施的核心組件之一，用于在不同服務或應用之間可靠、高效地傳輸數(shù)據。隨著企業(yè)業(yè)務規(guī)模擴大與系統(tǒng)復雜度的提升，消息系統(tǒng)通過異步解耦和削峰填谷等關鍵能力，顯著提升了系統(tǒng)的彈性與可擴展性。它使得數(shù)據處理流程更具靈活性，業(yè)務組件之間能夠獨立演進，同時有效應對突發(fā)流量，保障系統(tǒng)穩(wěn)定運行。構建高效的消息系統(tǒng)不僅有助于實現(xiàn)實時數(shù)據傳輸與多應用協(xié)同，更為企業(yè)未來的數(shù)據驅動決策奠定了堅實基石。

背景介紹

消息系統(tǒng)是一種在不同軟件組件或服務之間實現(xiàn)消息傳遞與協(xié)調的中間件平臺。其核心職能是確保消息能夠可靠、高效地從發(fā)送方傳遞至接收方，并支持多種通信模式，如發(fā)布 / 訂閱和點對點傳輸。隨著分布式架構和微服務模式的普及，消息系統(tǒng)已成為企業(yè)實現(xiàn)系統(tǒng)間松耦合與數(shù)據同步的重要工具。

消息系統(tǒng)通常包含若干基礎概念。Topic 是消息的邏輯分類單位，生產者（Producer）將消息發(fā)布到指定 Topic，消費者（Consumer）則通過訂閱相應 Topic 來接收消息；Producer 是消息的發(fā)送端，Consumer 是消息的接收端，Broker 作為中間節(jié)點負責消息的接收、存儲和路由。此外，多租戶（Multi-tenancy）機制支持在同一消息平臺上為不同業(yè)務線或團隊提供資源隔離與獨立命名空間，從而提升系統(tǒng)整體資源利用率和管理效率。其他重要概念還包括消息持久化、訂閱模式（如獨占、共享和災備模式）、消息順序性、重試機制和死信隊列等，這些共同構成了消息系統(tǒng)穩(wěn)定運行的基礎架構。

消息系統(tǒng)的典型使用場景包括：

• 異步解耦：消息系統(tǒng)將緊耦合的組件分離，生產者在完成主要邏輯后即可返回，無需等待消費者處理，顯著提升系統(tǒng)響應速度和容錯能力。

• 削峰填谷：消息隊列作為緩沖層，有效平衡生產與消費速率差異，避免突發(fā)流量沖垮后端服務，保證系統(tǒng)平穩(wěn)運行。

• 事件驅動架構（EDA）：作為事件總線傳遞狀態(tài)變更事件，觸發(fā)下游業(yè)務流程執(zhí)行。

• 數(shù)據同步：消息系統(tǒng)能實現(xiàn)跨系統(tǒng)、跨地域的數(shù)據復制，保證數(shù)據最終一致性。

• 流處理管道：連接實時數(shù)據源與流計算引擎，支持復雜事件處理與實時分析。

此外，消息系統(tǒng)還常用于日志收集、消息推送、任務隊列調度和微服務協(xié)同等場景，為現(xiàn)代分布式系統(tǒng)提供靈活可靠的通信基礎。

從業(yè)務價值角度看，消息系統(tǒng)不僅支撐了實時數(shù)據傳輸和多系統(tǒng)協(xié)同，還顯著提升了架構響應業(yè)務變化的敏捷性。它幫助企業(yè)構建高可用的分布式系統(tǒng)，降低模塊間的耦合度，增強系統(tǒng)對流量波動的適應能力。通過提供可靠的消息傳遞保證，消息系統(tǒng)為關鍵業(yè)務場景如金融交易、訂單處理、實時監(jiān)控等提供了堅實的數(shù)據流轉基礎。同時，標準化消息平臺的建設有助于企業(yè)整合異構系統(tǒng)，統(tǒng)一數(shù)據流通范式，為數(shù)字化轉型提供核心基礎設施支撐。具備良好擴展性和運維友好性的消息系統(tǒng)，正日益成為企業(yè)構建現(xiàn)代數(shù)據架構的戰(zhàn)略性組成部分。

選型指南

在企業(yè)級消息系統(tǒng)構建過程中，技術選型是至關重要的一環(huán)。目前主流的開源消息系統(tǒng)包括 Apache Kafka、Apache Pulsar、RabbitMQ、Apache RocketMQ 和 NATS，它們各有特色，適用于不同場景。Kafka 以其高吞吐和成熟生態(tài)著稱，Pulsar 作為云原生時代的新一代消息流平臺，憑借其存算分離架構和全球化部署能力脫穎而出；RabbitMQ 以靈活的路由和協(xié)議支持見長；RocketMQ 在順序消息和事務場景表現(xiàn)優(yōu)異；而 NATS 則極致追求輕量級和高性能。下面將分別介紹這些系統(tǒng)，并通過綜合對比表格輔助選型決策。

Apache Kafka

Kafka 最初由 LinkedIn 于 2011 年開發(fā)并開源，2012 年成為 Apache 孵化項目，2014 年正式畢業(yè)成為頂級項目。它采用分區(qū)和多副本機制構建分布式架構，依賴 ZooKeeper 進行元數(shù)據管理和協(xié)調（新版本已逐步轉向去 ZooKeeper 的 KRaft 模式）。Kafka 的設計哲學以高吞吐量為首要目標，支持持久化存儲與容錯機制，提供至少一次和精確一次的消息投遞語義。它與主流流處理框架（如 Flink、Spark Streaming）深度集成，構建了完整的流處理生態(tài)。Kafka 非常適用于日志聚合、實時流處理和大規(guī)模事件流場景，但其傳統(tǒng)的存算耦合架構在云原生環(huán)境下的彈性伸縮存在一定局限（LinkedIn 已于 2025 年轉向新的自研存算分離消息系統(tǒng)）。

Apache Pulsar

Pulsar 誕生于 2012 年雅虎內部項目，2016 年開源并捐贈給 Apache 基金會，2018 年 9 月畢業(yè)成為頂級項目。其革命性的計算與存儲分離架構，無狀態(tài) Broker 負責消息收發(fā)，Apache BookKeeper 提供持久化存儲，天然支持云原生部署和彈性擴縮容。Pulsar 支持多租戶隔離、分層存儲、跨地域復制和延遲消息等企業(yè)級特性，提供統(tǒng)一的消息隊列和流處理模型，既能以高吞吐、高性能支撐傳統(tǒng)消息隊列需求，又能以高可靠、高一致、高可用的特性支持流處理場景。特別值得一提的是，Pulsar 通過 Kafka-on-Pulsar（KoP）和 RabbitMQ-on-Pulsar（AoP）協(xié)議處理插件，支持從 Kafka 和 RabbitMQ 無縫遷移，大大降低了用戶遷移成本。Pulsar 適用于金融交易、物聯(lián)網數(shù)據處理、實時分析和跨地域部署等對一致性、可靠性和擴展性要求極高的場景。

RabbitMQ

由 Rabbit Technologies 于 2007 年基于 AMQP 協(xié)議開發(fā)，現(xiàn)由 VMware 旗下的 Spring 團隊維護。其核心架構采用"生產者 - 交換機 - 隊列 - 消費者"模型，通過多種交換機類型（Direct、Topic、Fanout、Headers）實現(xiàn)靈活的消息路由，支持 AMQP、MQTT、STOMP 等多種協(xié)議。RabbitMQ 提供消息持久化、確認機制、死信隊列和鏡像隊列等可靠性保障機制，管理界面友好，插件生態(tài)豐富。它非常適合傳統(tǒng)企業(yè)應用集成、微服務異步解耦和任務隊列場景，但在超大規(guī)模吞吐和橫向擴展方面存在一定限制。

Apache RocketMQ

由阿里巴巴于 2012 開發(fā)并開源，2016 年捐贈給 Apache，2017 年正式畢業(yè)成為頂級項目。其架構包含 NameServer（負責元數(shù)據管理）、Broker（負責消息存儲）、Producer 和 Consumer 四個核心組件，支持順序消息、分布式事務消息、消息過濾和軌跡追蹤等特性。RocketMQ 有低延遲、高可靠和高實時性的特點，廣泛應用于電商、金融和物聯(lián)網等場景。

NATS

NATS 由 Derek Collison 創(chuàng)建，最初源于 VMware 的研究項目，2015 年正式開源。NATS 采用極簡設計哲學，提供"最多一次"傳輸語義，聚焦高性能和可擴展性，不支持消息持久化、事務或增強交付模式。NATS 包含兩個版本：NATS Core 提供基礎消息功能，NATS JetStream 提供持久化和至少一次語義。它適用于微服務間同步 / 異步通信、服務發(fā)現(xiàn)和內部數(shù)據總線等對持久性要求不高的輕量級場景。

下表從多個維度對上述消息系統(tǒng)進行綜合對比，旨在為企業(yè)選型提供參考：

從對比中可以看出，Pulsar 在可擴展性、多租戶支持、跨地域復制和統(tǒng)一消息流處理方面表現(xiàn)突出，其云原生架構特別適合現(xiàn)代企業(yè)全球化部署和彈性伸縮的需求。Pulsar 的一站式特性使其既能以高吞吐高性能支撐傳統(tǒng)消息隊列需求，又能以高可靠高一致高可用性能支持流處理場景，同時通過協(xié)議兼容性大大降低了從 Kafka 或 RabbitMQ 遷移的技術門檻。Kafka 適合日志和流處理場景，RabbitMQ 適用于傳統(tǒng)企業(yè)應用，RocketMQ 適合在線場景的事務處理，NATS 則適合內部服務通信。企業(yè)應結合自身業(yè)務規(guī)模、運維能力和場景特性進行選擇，若追求高性能、低延遲和未來可擴展性，Pulsar 無疑是更面向未來的選擇。

應用實踐

騰訊計費平臺高可用消息系統(tǒng)建設

騰訊計費平臺（米大師）作為支撐騰訊內部業(yè)務千億級營收的核心系統(tǒng)，需要處理全球 180 多個國家地區(qū)的支付交易，托管 300 多億賬戶，為上萬業(yè)務代碼提供計費服務。在這個龐大的計費體系下，確保每筆交易的"錢貨一致"成為最關鍵的業(yè)務要求。平臺自研的分布式交易引擎 TDXA 致力于解決應用層交易一致性問題，而消息系統(tǒng)作為整個架構的重要組成，為交易事務提供了高可靠的消息通道保障。

業(yè)務痛點與挑戰(zhàn)

騰訊計費面臨的核心挑戰(zhàn)在于如何保障分布式環(huán)境下的交易一致性。系統(tǒng)需要處理每日 100 億 + 的交易請求，跨越 80 多個支付渠道和 300 多個業(yè)務邏輯，調用鏈路長且復雜。網絡超時、系統(tǒng)故障等異常情況頻繁發(fā)生，特別是在海外支付業(yè)務中更為明顯。同時，在類似王者榮耀周年慶等大型活動期間，系統(tǒng)需要承受 10 倍以上的流量突發(fā)，對消息系統(tǒng)的吞吐量和穩(wěn)定性提出極高要求。此外，系統(tǒng)還需要提供實時對賬能力，盡早發(fā)現(xiàn)并解決交易異常，保障用戶體驗。

技術選型

在消息系統(tǒng)選型過程中，團隊對 Kafka、RocketMQ 和 Pulsar 進行了深入評估。Kafka 雖然在大數(shù)據日志處理方面表現(xiàn)優(yōu)異，但其在金融級一致性保障方面存在不足；RocketMQ 則存在 Topic 運營不友好、不支持按 Topic 刪除失效消息等局限。最終選擇 Pulsar 主要基于以下考量：首先，Pulsar 基于 BookKeeper 的存儲架構天然提供強一致性保證，滿足計費系統(tǒng)"數(shù)據一條不能丟"的基本要求；其次，存算分離架構便于水平擴展，能夠應對海量消息堆積需求；此外，Pulsar 支持多租戶和多域部署，與騰訊計費的全球化業(yè)務布局高度契合；最后，其豐富的消費模式和毫秒級響應時間能夠滿足億級支付場景下的性能要求。

業(yè)務實踐與優(yōu)化

在實際落地過程中，團隊對 Pulsar 進行了深度優(yōu)化。針對計費場景常見的延遲消息需求，開發(fā)了 Delay Topic 和 Time wheel 兩種模式，支撐超時重試和營銷活動場景。引入二級 Tag 機制，在不增加 Topic 管理負擔的前提下，實現(xiàn)了按業(yè)務代碼過濾消息的能力。建設了完善的控制臺系統(tǒng)，實現(xiàn)對消息全生命周期的追蹤管理，包括消息內容查詢、生產者溯源和消費狀態(tài)監(jiān)控。構建了多維監(jiān)控告警體系，通過積壓告警、延遲告警和失敗告警等機制，確保系統(tǒng)異常能夠秒級發(fā)現(xiàn)并及時處理。

目前，騰訊計費平臺已部署 8 大 Pulsar 集群，管理 600+ 個 Topic，日均處理 100 億 + 交易請求，峰值 QPS 達到 50 萬 +，日均消費數(shù)據量超過 10TB。系統(tǒng)實現(xiàn)了 5 個 9 的高可用性，通過統(tǒng)一的 HTTP proxy 接入支持多語言客戶端，并在客戶端層面增加了生產失敗重試和降級容災能力。這些實踐不僅保障了計費系統(tǒng)的高可靠運行，也為其他金融級應用場景提供了可復用的消息系統(tǒng)建設經驗。

華為終端云消息系統(tǒng)中臺建設實踐

華為終端云服務作為華為終端業(yè)務的核心組成部分，為全球用戶提供云空間、應用市場、視頻、音樂等全方位數(shù)字生活服務。面對日益復雜的業(yè)務場景和快速增長的數(shù)據規(guī)模，華為終端云將其消息系統(tǒng)從 Kafka 遷移至 Apache Pulsar，并基于 Pulsar 構建了統(tǒng)一的消息隊列中臺，有效解決了多集群運維復雜、資源利用率低、容災建設困難等核心挑戰(zhàn)。

業(yè)務痛點與挑戰(zhàn)

華為終端云消息系統(tǒng)支撐著手機推送、游戲中心、應用市場等多個關鍵業(yè)務場景，原有基于 Kafka 的架構面臨四大核心挑戰(zhàn)。首先是多集群運維復雜度高，不同業(yè)務需維護多種消息隊列集群，缺乏統(tǒng)一的高級特性支持（如延遲消息、死信消息、海量分區(qū)等）。其次是云原生環(huán)境適配能力不足，Kafka 擴容需人工干預和數(shù)據遷移，過程耗時且影響業(yè)務性能。第三是容災建設困難，跨 AZ 容災存在網絡延遲導致的性能下降問題，主備容災模式資源閑置率高。最后是資源利用率低下，計算資源因業(yè)務隔離難以提升，存儲資源因需預留冗余空間導致磁盤利用率不足，整體建設成本居高不下。

技術選型

在全面評估后，華為終端云選擇 Apache Pulsar 作為新一代消息系統(tǒng)核心。Pulsar 的存算分離架構完美適配云原生環(huán)境，支持秒級伸縮且對業(yè)務無感知；多協(xié)議接入能力（Kafka、Flink、RESTful 等）使得一套集群即可滿足多樣化業(yè)務需求；原生支持延遲消息、死信消息等高級特性，避免了多系統(tǒng)維護的復雜性。此外，Pulsar 的跨 AZ 容災機制通過優(yōu)化機架感知和副本分布策略，顯著降低了網絡延遲對性能的影響。這些特性使 Pulsar 成為華為終端云構建統(tǒng)一消息中臺的理想選擇。

業(yè)務實踐與優(yōu)化

在落地實踐中，華為終端云基于 Pulsar 構建了統(tǒng)一的消息隊列中臺。首先實現(xiàn)了多協(xié)議接入和統(tǒng)一 SDK 封裝，業(yè)務無需感知底層消息系統(tǒng)差異，后續(xù)可無縫更換內核。針對云原生環(huán)境，利用 Pulsar 的存算分離特性，實現(xiàn)了 Bookie 節(jié)點分鐘級擴容（相比 Kafka 數(shù)小時的大幅提升），并通過優(yōu)化流量均衡算法解決節(jié)點重啟后的流量分配問題。

在容災建設方面，團隊在 Pulsar 社區(qū)版本基礎上優(yōu)化了跨 AZ 標簽能力，支持單元化部署和故障自動降級機制。創(chuàng)新性地提出共享逃生池方案，打破 1:1 容災集群模式，實現(xiàn)多套主集群共享一套逃生集群，使容災成本下降 20% 以上，CPU 使用率提升 10%。

資源利用率提升方面，通過容器化管理和存儲資源池化，實現(xiàn)了計算和存儲資源的動態(tài)伸縮與共享。Pulsar 的無狀態(tài) Broker 易于容器化部署，而有狀態(tài) Bookie 節(jié)點通過元數(shù)據集中管理，為構建統(tǒng)一存儲池奠定了基礎。這些優(yōu)化措施顯著提升了資源利用率，降低了整體運營成本。

目前，華為終端云基于 Pulsar 的消息中臺已穩(wěn)定支撐多個核心業(yè)務場景，實現(xiàn)了運維復雜度降低、性能提升和成本優(yōu)化的多重目標。未來團隊計劃進一步完善存儲池化建設，提升集群應對突發(fā)流量的彈性能力，持續(xù)優(yōu)化消息系統(tǒng)的可靠性和經濟性。

小紅書消息中間件架構升級實踐

小紅書作為領先的生活方式分享平臺，其消息中間件系統(tǒng)承擔著平臺實時數(shù)據流轉的重要職責。面對業(yè)務規(guī)模的快速增長，小紅書對消息系統(tǒng)進行了全面的架構升級，從原有的 RocketMQ 架構轉向以 Apache Pulsar 為核心的新一代云原生消息平臺，實現(xiàn)了顯著的性能提升和成本優(yōu)化。

業(yè)務痛點與挑戰(zhàn)

小紅書原有的消息系統(tǒng)基于 DDMQ 架構，采用 Discovery + Proxy + RocketMQ 引擎的組合模式。該架構在業(yè)務發(fā)展過程中逐漸暴露出多個問題：客戶端場景覆蓋不足導致多種連接方式共存，數(shù)據平臺類接入難以全面覆蓋；管控平臺、服務發(fā)現(xiàn)和 Proxy 之間的協(xié)同復雜度高，運維成本大幅提升；RocketMQ 的存儲架構存在資源浪費，Slave 副本 CPU 利用率僅為 7%，遠低于 Master 節(jié)點的 50%；彈性擴展能力不足，無法實現(xiàn)按需擴縮容和按量計費。這些問題嚴重制約了消息系統(tǒng)的效率和可擴展性。

技術選型

在 Pulsar 與 RocketMQ 5.x 的選型評估中，小紅書團隊從多個維度進行了深入分析。Pulsar 的存算分離架構帶來顯著優(yōu)勢：通過多盤部署實現(xiàn)存儲成本降低 27%，磁盤帶寬提升 71%；副本流量對等機制有效解決資源浪費問題，CPU 利用率提升 43%，相應降低 21.5% 的 CPU 資源成本；彈性伸縮特性可實現(xiàn)按需資源分配，預計節(jié)省 30% 資源用量。此外，Pulsar 的云原生架構支持平滑擴縮容，計算層 Broker 無狀態(tài)設計實現(xiàn)流量自動均衡，存儲層 BookKeeper 支持新節(jié)點自動流量覆蓋。這些特性使 Pulsar 成為小紅書消息中間件升級的理想選擇。

業(yè)務實踐與優(yōu)化

在落地實踐中，小紅書制定了清晰的遷移策略和架構升級方案。首先推動客戶端標準化，通過 EventClient 統(tǒng)一接入方式，實現(xiàn)各類語言和場景的全覆蓋。遷移過程采用按業(yè)務優(yōu)先級從低到高逐步推進的方式，確保平滑遷移用戶無感。新架構基于 Pulsar 構建存算分離的云原生底座，提供跨云多活、實時隊列、延遲隊列、分層存儲和彈性計費等特色功能。

在實施過程中，團隊重點關注成本優(yōu)化和性能提升。通過多盤部署和廉價盤組合，在保持相同 CPU、內存和存儲容量的前提下，實現(xiàn)存儲成本下降和帶寬提升；利用副本流量對等特性，將 CPU 使用率從原來的 34%（主 62%、從 7%）提升到 60%；通過彈性伸縮機制，根據實際使用量動態(tài)調整資源配額，減少資源冗余。同時建立了完善的監(jiān)控體系，通過全鏈路探針實現(xiàn)端到端可觀測性。

目前，新架構已承載 11.8% 的流量，取得顯著成效：成本降低 42%，客戶端端到端延時從 20.2ms 降至 5.7ms，人工運維工作量大幅減少。長遠規(guī)劃包括完成 Pulsar 全量遷移、推進客戶端標準化 100% 覆蓋、加強穩(wěn)定性建設，最終實現(xiàn) RocketMQ 集群下線，全面轉向 Pulsar 云原生消息平臺。

vivo 海量數(shù)據場景下的消息系統(tǒng)架構演進

vivo 移動互聯(lián)網業(yè)務為全球超過 4 億用戶提供應用商店、短視頻、廣告等服務，其分布式消息中間件平臺承擔了實時數(shù)據接入與分發(fā)的關鍵角色，日均處理數(shù)據量達十萬億級別。面對業(yè)務規(guī)模的持續(xù)增長，vivo 在消息系統(tǒng)架構演進中通過引入 Apache Pulsar，有效解決了原有 Kafka 架構在多集群管理、彈性擴縮容和海量分區(qū)場景下面臨的諸多瓶頸。

業(yè)務痛點與挑戰(zhàn)

隨著 vivo 業(yè)務流量的數(shù)十倍增長，原有基于 Kafka 的消息系統(tǒng)逐漸顯露出架構局限性。Topic 和分區(qū)數(shù)量的持續(xù)增加嚴重影響了集群性能，大量分區(qū)導致磁盤隨機讀寫加劇，違背了 Kafka 依賴順序讀寫實現(xiàn)高性能的設計初衷。集群規(guī)模擴張后，資源組隔離與集群拆分的運維成本顯著上升，且 Kafka 無法實現(xiàn)動態(tài)擴縮容，機器資源利用率低。在面對突發(fā)流量時，擴容速度緩慢，流量均衡耗時較長，消費端性能過度依賴分區(qū)數(shù)量，造成元數(shù)據急劇膨脹。此外，集群基數(shù)增大導致硬件故障頻發(fā)，且故障直接傳導至客戶端，缺乏有效的中間容錯層。

技術選型

在綜合評估集群穩(wěn)定性、擴展能力和運維成本后，vivo 選擇引入 Apache Pulsar 作為新一代消息中間件。Pulsar 的存算分離架構帶來顯著優(yōu)勢：無狀態(tài) Broker 支持快速擴縮容，存儲層基于 BookKeeper 實現(xiàn)數(shù)據均勻分布和高可用保障。其獨有的 Bundle 機制能夠以有限的邏輯單元管理海量 Topic，有效避免元數(shù)據膨脹問題。Pulsar 支持多種消費模式（Exclusive、Failover、Shared、Key_Shared），消費能力擴展不再完全依賴分區(qū)數(shù)量，Shared 模式可實現(xiàn)多個消費者并行處理，Key_Shared 模式則在共享消費的同時保證消息順序性。這些特性使 Pulsar 能夠更好地應對 vivo 業(yè)務場景中的流量突發(fā)、故障恢復和彈性擴展需求。

業(yè)務實踐與優(yōu)化

在落地實踐中，vivo 重點優(yōu)化了 Pulsar 的 Bundle 管理機制，通過合理設置 Bundle 數(shù)量范圍和拆分策略，確保流量在 Broker 間的均衡分布。針對數(shù)據管理，團隊優(yōu)化了 Ledger 翻轉參數(shù)，防止單個 Ledger 過大導致的數(shù)據存儲不均衡問題。建立了統(tǒng)一的數(shù)據保留策略，將 TTL 與 Retention 周期對齊，簡化數(shù)據過期處理流程。在監(jiān)控方面，vivo 構建了基于 Prometheus + Kafka + Druid 的指標采集和存儲體系，開發(fā)了包括 Bundle 分布、讀寫延遲 P95/P99、網絡負載等在內的多維監(jiān)控指標。

針對實際應用中發(fā)現(xiàn)的負載均衡和客戶端性能問題，團隊進行了系列優(yōu)化：調整負載均衡參數(shù)，將節(jié)點流量偏差控制在 20% 以內；通過增加分區(qū)數(shù)量改善 Bundle 分配均衡性；優(yōu)化客戶端發(fā)送參數(shù)配置，顯著提升發(fā)送性能；實施"能者多勞"的發(fā)送策略，解決單個分區(qū)阻塞影響整體發(fā)送性能的問題。這些優(yōu)化措施使得 Pulsar 集群在 vivo 環(huán)境中穩(wěn)定支撐千億級消息流量，有效應對各類異常場景，為業(yè)務提供高可靠、低延遲的消息服務。

滴滴大數(shù)據運維實踐

滴滴大數(shù)據團隊于 2021 年 1 月開始調研 Apache Pulsar，同年 8 月正式上線首個 Pulsar 集群，支撐數(shù)據開發(fā)平臺和同步中心的數(shù)據通道同步任務。經過兩年多的穩(wěn)定運行，Pulsar 成功替代了原有的 DKafka（基于 Kafka 2.12-0.10.2.0）系統(tǒng)，有效解決了長期困擾團隊的運維難題，實現(xiàn)了性能、成本和可靠性的全面提升。

業(yè)務痛點與挑戰(zhàn)

滴滴大數(shù)據原有的 DKafka 系統(tǒng)面臨多重運維挑戰(zhàn)。首先是磁盤 IO 瓶頸問題，當 Broker 承載成百上千個 Topic 分區(qū)時，磁盤寫入由順序變?yōu)殡S機，導致性能急劇下降，生產消費耗時顯著增加。其次是集群容量限制，盡管團隊曾嘗試用 SSD 替代 SATA 盤，但成本高昂且仍存在單盤熱點問題，不得不降低副本數(shù)和存儲周期。此外，系統(tǒng)還存在緩存與 IO 未隔離、單盤單機存儲熱點、元數(shù)據過多導致 Rebalance 壓力大、負載均衡復雜以及擴縮容困難等問題。這些痛點使得運維團隊需要投入大量人力進行監(jiān)控和干預，嚴重影響了集群的穩(wěn)定性和資源利用率。

技術選型理由

在全面評估后，滴滴大數(shù)據團隊選擇 Apache Pulsar 作為新一代消息系統(tǒng)。Pulsar 的存算分離架構通過 BookKeeper 實現(xiàn)順序刷盤，徹底解決了隨機寫入導致的 IO 瓶頸問題；其多級緩存機制（包括 Broker 堆外緩存和 Bookie 讀寫緩存）有效實現(xiàn)了 IO 隔離，避免了讀寫相互影響；Bundle 機制將海量分區(qū)映射到有限哈希環(huán)上，大幅降低了元數(shù)據管理和 Rebalance 壓力；節(jié)點對等和無狀態(tài)設計使得擴縮容變得簡單高效，支持高峰期和故障期間的快速擴容。這些特性使 Pulsar 成為解決滴滴大數(shù)據運維痛點的理想選擇。

業(yè)務實踐與優(yōu)化

在落地實踐中，團隊重點優(yōu)化了以下幾個方面。硬件選型采用 SATA HDD 盤 +NVME 的異構機型，NVME 作為 journal 和 index 存儲介質，在降低成本的同時延長了存儲周期并增加了副本數(shù)。通過利用 Pulsar 的 Ensemble 機制，實現(xiàn)數(shù)據自動均衡分布，集群中所有數(shù)據盤的存儲容量利用率差異控制在 10% 以內，徹底解決了存儲熱點問題。運維方面，借助 Bundle 機制實現(xiàn)一鍵式負載均衡，熱點 Broker 上的 bundle 可快速卸載并自動分配到最優(yōu)節(jié)點，大幅提升了運維效率。

在擴縮容方面，Pulsar 展現(xiàn)出顯著優(yōu)勢。計算層 Broker 擴容后可通過 bundle 漂移立即分擔負載；存儲層 Bookie 擴容后無需數(shù)據遷移，新數(shù)據自動選擇低負載節(jié)點寫入，實現(xiàn)了新老節(jié)點的"雙向奔赴"。故障恢復能力也得到極大增強，計算層無狀態(tài)設計支持快速故障轉移，存儲層通過 readonly 模式和快速擴容確保服務連續(xù)性。這些改進使得滴滴大數(shù)據平臺能夠應對各種突發(fā)狀況，保障數(shù)據通道的穩(wěn)定運行。

目前，Pulsar 集群已在滴滴大數(shù)據平臺穩(wěn)定運行兩年多，成功支撐了 Log->ES、BamaiLog->ES、BamaiLog->CK 和 Log->HDFS 等重要數(shù)據同步鏈路。相比原有的 DKafka 系統(tǒng)，Pulsar 在性能、成本和可靠性方面都帶來了顯著提升，為滴滴大數(shù)據業(yè)務的發(fā)展提供了堅實的技術保障。

運維保障

構建穩(wěn)定可靠的消息系統(tǒng)離不開完善的運維保障體系。這一體系應當貫穿技術預研、部署上線和日常運營的全生命周期，其核心目標是確保系統(tǒng)高可用性，并在故障發(fā)生時能夠快速應急響應。

在技術預研階段，就需要提前考慮線上可能出現(xiàn)的緊急故障及應對方案。技術驗證包括業(yè)務驗證和壓測兩個關鍵環(huán)節(jié)。業(yè)務驗證重點考察產品特性與業(yè)務模型的匹配度，包括消費模型（Shared、Key-Shared 或 Exclusive 等）和消息特性（如延遲隊列、死信隊列等）的適配性。從運維角度，壓測更為重要，需要根據業(yè)務場景確定數(shù)據可靠性等級，這直接決定了副本數(shù)量和刷盤策略的選擇。同步刷盤保證數(shù)據強一致但性能較低，異步刷盤則提供更高吞吐但可能丟失少量數(shù)據。

部署上線前必須消除單點故障，完善監(jiān)控體系并建立應急機制。壓測的目標是在給定硬件配置下確定集群負載的三個關鍵指標：理論性能上限（Max 值）、長期穩(wěn)定運行的容量值（High 值）和正常擴容閾值（Normal 值）。其中 High 值是最需要關注的運維指標，它表示系統(tǒng)在保持相對穩(wěn)定狀態(tài)下的最大負載能力，超過這個值將大幅增加故障風險。基于這三個指標設置分級告警至關重要，當達到 Normal 值時需要通知擴容，達到 High 值時則需立即應急處理。

日常運營的核心是降低故障發(fā)生概率。通過混沌工程定期進行故障演練，驗證監(jiān)控系統(tǒng)的完備性和應急方案的有效性。任何一個故障演練都應在監(jiān)控系統(tǒng)中留下痕跡，否則需要重新評估監(jiān)控指標采集的完整性。應急機制應包括限流和隔離措施，限流可保證系統(tǒng)在極端情況下不致崩潰，隔離能將熱點數(shù)據與普通數(shù)據分開處理。

運維人員應始終牢記三個關鍵問題：系統(tǒng)是否存在單點故障？監(jiān)控是否完備？是否有應急預案？這"運維三板斧"是保障系統(tǒng)穩(wěn)定性的基礎。同時要嚴格控制變更類和突發(fā)類事件的影響，版本變更需經過灰度發(fā)布，流量突發(fā)需依靠 High 值指導和單點消除來應對。通過以上措施，可以構建一個健壯的消息系統(tǒng)運維保障體系，確保系統(tǒng)長期穩(wěn)定運行。

總結與展望

本文系統(tǒng)性地闡述了企業(yè)級消息系統(tǒng)的構建全流程，從消息系統(tǒng)的基礎概念與核心價值出發(fā)，深入分析了主流技術選型的特性與適用場景，并提供了從部署上線到日常運維的完整保障體系。隨著 AI 與大數(shù)據產業(yè)的發(fā)展，消息系統(tǒng)已成為企業(yè)數(shù)據基礎設施中不可或缺的組成部分，為業(yè)務系統(tǒng)提供了可靠的數(shù)據流轉基礎。

展望未來，隨著 AI 數(shù)據基礎設施的快速發(fā)展，消息系統(tǒng)將面臨新的機遇與挑戰(zhàn)。一方面，多智能體協(xié)同系統(tǒng)將成為 AI 應用的重要形態(tài)，其底層需要高性能、低延遲的消息中間件來支持海量智能體之間的通信與協(xié)作。另一方面，實時機器學習管道對數(shù)據流的時效性和一致性提出了更高要求，需要消息系統(tǒng)能夠支撐從數(shù)據采集、預處理到模型推理的全鏈路實時數(shù)據流。

在這些新興場景中，新一代云原生消息系統(tǒng)展現(xiàn)出顯著優(yōu)勢。其存算分離架構天然適合彈性伸縮的 AI 工作負載，跨地域復制能力為分布式訓練提供數(shù)據同步保障，統(tǒng)一的消息和流處理模型能夠簡化 AI 數(shù)據管道架構。同時，強一致性保證和多租戶隔離特性為多團隊協(xié)作的 AI 開發(fā)提供了理想基礎。隨著企業(yè) AI 應用的深入，消息系統(tǒng)必將在構建智能數(shù)據基礎設施中發(fā)揮更加關鍵的作用。

參考資料

(1)Apache Kafka (https://kafka.apache.org/)

(2)Apache Pulsar (https://pulsar.apache.org/)

(3)RabbitMQ: One broker to queue them all | RabbitMQ (https://www.rabbitmq.com/)

(4)RocketMQ · 官方網站 | RocketMQ （https://rocketmq.apache.org/）

(5)NATS.io – Cloud Native, Open Source, High-performance Messaging（https://nats.io/ ）

(6)Apache Pulsar 在騰訊計費場景下的應用 _ 大數(shù)據 _ 劉德志 _InfoQ 精選文章（https://www.infoq.cn/article/qvxrkboa_7h0g6viptyl ）

(7)

(8)

(9)

(10)