“Make MQ Great Again”這個(gè)口號(hào)出現(xiàn)在 COSCon‘25 與 Pulsar Developer Day 2025 的聯(lián)合會(huì)場(chǎng)上多少有些讓人會(huì)心一笑。作為一個(gè)從 ActiveMQ 時(shí)代寫消費(fèi)端出身、后來(lái)又折騰過(guò) Kafka 和 RocketMQ 的后端我對(duì)這個(gè)消息隊(duì)列的“文藝復(fù)興”主題既熟悉又好奇。消息中間件這個(gè)看似基礎(chǔ)、看似穩(wěn)定的領(lǐng)域在數(shù)據(jù)量爆炸、云原生普及、AI 應(yīng)用大規(guī)模落地的當(dāng)下正在經(jīng)歷一場(chǎng)并不喧嘩但非常硬核的重塑。這篇回顧寫的是我全程參加這場(chǎng)活動(dòng)后的所見(jiàn)、所聞和所得既有會(huì)場(chǎng)里的高密度技術(shù)分享也有我在現(xiàn)場(chǎng)親手跑通的小實(shí)驗(yàn)還有一些會(huì)后回來(lái)自己驗(yàn)證過(guò)的經(jīng)驗(yàn)。如果你想了解 Pulsar 為什么能在 2025 年重新把 MQ 這個(gè)老話題講出新內(nèi)容或者正在為團(tuán)隊(duì)選型消息系統(tǒng)而糾結(jié)這篇內(nèi)容應(yīng)該能給你一些參考。1. 開(kāi)場(chǎng)印象MQ 不是“老古董”而是正在換發(fā)動(dòng)機(jī)1.1 為什么“Make MQ Great Again”不是一句調(diào)侃活動(dòng)公布主題時(shí)很多人在群里轉(zhuǎn)發(fā)“Make MQ Great Again”第一反應(yīng)都是玩梗。但到了現(xiàn)場(chǎng)聽(tīng)了幾場(chǎng)分享之后我意識(shí)到這句話其實(shí)很認(rèn)真。消息隊(duì)列并不是一個(gè)需要“再次偉大”的過(guò)氣組件恰恰相反它在現(xiàn)代分布式系統(tǒng)里的位置比十年前更重要。過(guò)去我們聊 MQ主要是在聊削峰填谷、異步解耦、應(yīng)用間通信現(xiàn)在聊 MQ大家關(guān)心的是實(shí)時(shí)數(shù)倉(cāng)的接入層、AI Agent 的上下文傳遞、物聯(lián)網(wǎng)設(shè)備的海量事件接入、跨云跨地域的數(shù)據(jù)同步?；A(chǔ)能力沒(méi)變但承載的業(yè)務(wù)場(chǎng)景已經(jīng)換了一代。會(huì)場(chǎng)上有一張 PPT 我記得很清楚把現(xiàn)存主流消息系統(tǒng)的演進(jìn)按時(shí)間軸排列傳統(tǒng)企業(yè)級(jí) MQ、開(kāi)源消息中間件、分布式日志系統(tǒng)、云原生消息平臺(tái)依次出現(xiàn)。Pulsar 屬于最后那一檔但它并不是簡(jiǎn)單地“再做一款 Kafka”而是把底層存儲(chǔ)、計(jì)算、協(xié)議接入徹底拆開(kāi)。這個(gè)架構(gòu)動(dòng)機(jī)在多個(gè)演講里被反復(fù)強(qiáng)調(diào)讓一套引擎同時(shí)滿足隊(duì)列模型和流模型既保留消息確認(rèn)、死信、順序消費(fèi)這類 MQ 老用戶離不開(kāi)的語(yǔ)義又提供流式系統(tǒng)需要的分區(qū)、重放、高吞吐和水平擴(kuò)展?，F(xiàn)場(chǎng)有不少人問(wèn)“Pulsar 是不是要取代 Kafka”幾乎每個(gè)講師都會(huì)先糾正這個(gè)問(wèn)題。更準(zhǔn)確的說(shuō)法是Pulsar 想在 MQ 和流處理之間找到平衡點(diǎn)。Kafka 在流處理生態(tài)的地位短期內(nèi)難以撼動(dòng)但很多企業(yè)的真實(shí)場(chǎng)景其實(shí)是混合型的一部分流量要求低延遲、強(qiáng)一致的消息投遞另一部分流量需要長(zhǎng)時(shí)間保留、可回溯的流數(shù)據(jù)。傳統(tǒng)方案通常要同時(shí)維護(hù)兩套系統(tǒng)而 Pulsar 試圖用存儲(chǔ)和計(jì)算分離的架構(gòu)讓一套系統(tǒng)覆蓋兩種模式。這也是活動(dòng)主題叫“Make MQ Great Again”的原因——不是在懷舊而是給 MQ 換一套新發(fā)動(dòng)機(jī)。1.2 聯(lián)合場(chǎng)次的價(jià)值開(kāi)源大會(huì)與開(kāi)發(fā)者日擦出的火花這次是和 COSCon 合辦會(huì)場(chǎng)設(shè)置很有意思。COSCon 本身是綜合性開(kāi)源大會(huì)觀眾里有很多做前端、AI、操作系統(tǒng)、開(kāi)源的伙伴Pulsar Developer Day 則更垂直吸引的是消息系統(tǒng)和數(shù)據(jù)基礎(chǔ)設(shè)施的深度用戶。兩個(gè)群體放在一起產(chǎn)生了很奇妙的化學(xué)反應(yīng)。一個(gè)做輔助駕駛系統(tǒng)的工程師和一個(gè)做量化交易平臺(tái)的架構(gòu)師竟然在同一個(gè)圓桌上聊 Pulsar 的背壓機(jī)制一個(gè)剛接觸消息隊(duì)列的大學(xué)生在動(dòng)手實(shí)驗(yàn)區(qū)用二十分鐘起了本地集群眼睛里全是光。這種組合讓 Pulsar 的開(kāi)發(fā)者也意識(shí)到消息中間件的使用者正在變得更多元不再只是后端老炮。AI 應(yīng)用需要把大模型調(diào)用記錄、工具調(diào)用事件、多輪會(huì)話上下文全部以事件流的方式存儲(chǔ)和分發(fā)IoT 平臺(tái)需要面向海量設(shè)備維持百萬(wàn)級(jí)長(zhǎng)連接同時(shí)還要把設(shè)備狀態(tài)變更可靠地同步到業(yè)務(wù)系統(tǒng)。這些新場(chǎng)景沒(méi)有那么多歷史包袱反而更愿意嘗試新架構(gòu)?；顒?dòng)上好幾場(chǎng)演講的主題都集中在這些新用例上而不是單純講“我們比誰(shuí)吞吐高”。聯(lián)合辦會(huì)的好處就在這里做開(kāi)源的人能找到真實(shí)需求用開(kāi)源的人能找到落地路徑。2. 關(guān)鍵技術(shù)分享拆解Pulsar 的“新三樣”2.1 存儲(chǔ)計(jì)算分離為什么是必答題而不是選答題Pulsar 最核心的設(shè)計(jì)就是 Broker 和 BookKeeper 分離。Broker 只負(fù)責(zé)協(xié)議解析、鑒權(quán)、路由和緩存真正持久化數(shù)據(jù)的是一組獨(dú)立的 BookKeeper 節(jié)點(diǎn)。這個(gè)架構(gòu)讓擴(kuò)容變得非常優(yōu)雅需要提升讀寫吞吐就擴(kuò) Broker需要增加存儲(chǔ)容量或磁盤帶寬就擴(kuò) BookKeeper兩者完全獨(dú)立?，F(xiàn)場(chǎng)有講師把這種設(shè)計(jì)類比成“餐廳后廚和中央廚房分離”Broker 是前廳的傳菜口BookKeeper 是集中做菜的中央廚房高峰期可以直接加傳菜口的人手而不需要把整個(gè)后廚翻新一遍。對(duì)比之下傳統(tǒng)消息集群通常是“一體的”每個(gè)節(jié)點(diǎn)既處理請(qǐng)求又負(fù)責(zé)在本地磁盤上寫數(shù)據(jù)。集群擴(kuò)到一定規(guī)模后某個(gè)節(jié)點(diǎn)磁盤滿了或 IO 被打滿處理能力就立刻形成瓶頸。存儲(chǔ)計(jì)算分離不是新概念但在消息領(lǐng)域把這個(gè)概念做成真正穩(wěn)定大規(guī)模落地的Pulsar 算是最徹底的一個(gè)。BookKeeper 的 Segment 存儲(chǔ)模型把數(shù)據(jù)切成小段分布在多個(gè)節(jié)點(diǎn)上配合 Quorum 機(jī)制保證多副本寫入。當(dāng)一個(gè) BookKeeper 節(jié)點(diǎn)故障時(shí)系統(tǒng)自動(dòng)把該節(jié)點(diǎn)的 Segment 重新復(fù)制到其他節(jié)點(diǎn)整個(gè)過(guò)程對(duì) Broker 和客戶端透明。我在現(xiàn)場(chǎng)最關(guān)心的其實(shí)是這個(gè)架構(gòu)在日常運(yùn)維里的真實(shí)表現(xiàn)。有位分享嘉賓給了組數(shù)據(jù)他們?cè)?100 多個(gè) BookKeeper 節(jié)點(diǎn)上長(zhǎng)期運(yùn)行生產(chǎn)集群?jiǎn)稳障⒘砍^(guò)萬(wàn)億條。讓我印象更深的不是數(shù)字本身而是他提到“擴(kuò)存儲(chǔ)節(jié)點(diǎn)就像加一塊普通硬盤一樣”不用遷移既有分區(qū)不用重新做數(shù)據(jù)均衡。這一點(diǎn)對(duì)運(yùn)維團(tuán)隊(duì)非常友好也是很多開(kāi)源 MQ 在規(guī)模化之后最痛的點(diǎn)。2.2 多協(xié)議接入把“兼容”從口號(hào)變成可配置項(xiàng)Pulsar 原生支持多協(xié)議這件事以前只是在文檔里看到這次現(xiàn)場(chǎng)演示讓我徹底信服了。同一個(gè) Pulsar 集群可以同時(shí)用 Kafka 協(xié)議客戶端、Pulsar 原生協(xié)議、MQTT 協(xié)議、AMQP 協(xié)議接入。演示的工程師現(xiàn)場(chǎng)開(kāi)了一個(gè) Kafka 的 console consumer 直接消費(fèi) Pulsar topic 里的消息又從 MQTT 客戶端發(fā)布了一條遙測(cè)數(shù)據(jù)兩邊的消息能在同一個(gè) topic 上匯合。底下的觀眾先是安靜了一會(huì)兒隨后開(kāi)始密集提問(wèn)這個(gè)兼容是只做協(xié)議翻譯還是語(yǔ)義也完整映射答案比較令人安心Kafka 協(xié)議兼容層不是簡(jiǎn)單地把字節(jié)流轉(zhuǎn)換一下而是盡量對(duì)齊了消費(fèi)組、offset 提交、事務(wù)等核心語(yǔ)義。這意味著團(tuán)隊(duì)里已有的 Kafka 客戶端、監(jiān)控工具、甚至部分 Flink Connector 都可以直接連到 Pulsar 上遷移成本被大幅壓縮。MQTT 的支持則帶了一堆額外的性能調(diào)優(yōu)參數(shù)比如 QoS 級(jí)別、保留消息、遺囑消息那些從 EMQX 之類的生態(tài)遷過(guò)來(lái)的用戶會(huì)覺(jué)得很親切。這種多協(xié)議策略有一個(gè)特別實(shí)際的價(jià)值公司內(nèi)部往往同時(shí)有好幾套消息系統(tǒng)因?yàn)椴煌块T各自選型形成了 Kafka、RabbitMQ、Pulsar 甚至老牌企業(yè)級(jí) MQ 并存的局面。Pulsar 通過(guò)協(xié)議層粘合讓新老系統(tǒng)之間可以逐步遷移而非一次性推倒重來(lái)?，F(xiàn)場(chǎng)有個(gè)比喻我很認(rèn)同多協(xié)議不是讓你把所有雞蛋放進(jìn)一個(gè)籃子而是給你一個(gè)可以慢慢搬家的中轉(zhuǎn)站。2.3 分層存儲(chǔ)與無(wú)狀態(tài) Broker成本視角下的殺手锏過(guò)去消息系統(tǒng)很難做到長(zhǎng)期保存歷史數(shù)據(jù)要么存儲(chǔ)成本過(guò)高要么消費(fèi)歷史消息會(huì)把集群壓垮。Pulsar 的分層存儲(chǔ)把熱數(shù)據(jù)放在 BookKeeper冷數(shù)據(jù)可以自動(dòng)卸載到對(duì)象存儲(chǔ)比如 AWS S3、騰訊云 COS以及各類兼容 S3 的存儲(chǔ)。這個(gè)能力聽(tīng)起來(lái)很輕松實(shí)際背后是兩個(gè)硬核設(shè)計(jì)一是 Broker 可以只緩存熱數(shù)據(jù)的索引和元數(shù)據(jù)二是數(shù)據(jù)卸載和回讀的流程完全自動(dòng)化應(yīng)用層不需要感知?，F(xiàn)場(chǎng)展示了一個(gè)很“凡爾賽”的操作把一個(gè) topic 的 retention 設(shè)置成“不刪除”然后生產(chǎn)了幾百萬(wàn)條消息等數(shù)據(jù)自動(dòng)從 BookKeeper 卸載到對(duì)象存儲(chǔ)后再用一個(gè)剛啟動(dòng)的全新消費(fèi)組從頭開(kāi)始消費(fèi)。消費(fèi)過(guò)程中流量水位非常平?jīng)]有明顯的讀取毛刺。這套機(jī)制意味著我們可以真正把 MQ 當(dāng)作一個(gè)“流式數(shù)據(jù)湖”的入口而不是用完即棄的臨時(shí)管道。也正是因?yàn)?Broker 無(wú)狀態(tài)Pulsar 在 Kubernetes 上跑得非常順。Pod 調(diào)度、滾動(dòng)升級(jí)、故障自愈都不需要關(guān)心本地?cái)?shù)據(jù)。現(xiàn)場(chǎng)動(dòng)手實(shí)驗(yàn)環(huán)節(jié)主辦方用的就是一套 Kind 集群一條命令部署了 Pulsar Operator然后通過(guò) CRD 申請(qǐng)了一個(gè)三 BookKeeper、三 Broker 的集群。從提交 YAML 到集群 Ready 大概花了三四分鐘這個(gè)速度對(duì)開(kāi)發(fā)者體驗(yàn)來(lái)說(shuō)相當(dāng)重要。3. 動(dòng)手實(shí)驗(yàn)與實(shí)操記錄從零跑通一個(gè) Pulsar 集群3.1 實(shí)驗(yàn)環(huán)境準(zhǔn)備Docker Compose 快速起飛在活動(dòng)動(dòng)手區(qū)主辦方準(zhǔn)備了好幾臺(tái)實(shí)驗(yàn)機(jī)器配置不算高8 核 16G 內(nèi)存。大多數(shù)人第一選擇是用 Docker Compose 快速起一個(gè) standalone 集群。這條路徑對(duì)初學(xué)者最友好也是我建議第一次接觸 Pulsar 的朋友先嘗試的方式。下面是我在現(xiàn)場(chǎng)用到的啟動(dòng)文件片段回來(lái)之后我在自己電腦上又驗(yàn)證了一遍可以直接用。version: 3.8 services: pulsar: image: apachepulsar/pulsar:4.0.0 container_name: pulsar ports: - 6650:6650 - 8080:8080 environment: PULSAR_MEM: -Xms512m -Xmx512m -XX:MaxDirectMemorySize256m command: bin/pulsar standalone啟動(dòng)只需要兩分鐘docker compose up -d docker exec -it pulsar bin/pulsar-admin clusters list看到standalone輸出就說(shuō)明服務(wù)已經(jīng)起來(lái)了。這里要注意新版 Pulsar 的 standalone 模式和舊版細(xì)節(jié)差異比較大一些老文章中讓改standalone.conf的配置在這里不一定生效建議優(yōu)先查看官方文檔里對(duì)應(yīng)版本的部分。啟動(dòng)后可以立刻跑一個(gè)生產(chǎn)消費(fèi)的連通性驗(yàn)證docker exec -it pulsar bin/pulsar-client produce persist://public/default/test -m hello coscon -n 1 docker exec -it pulsar bin/pulsar-client consume persist://public/default/test -n 1 -p Earliest這個(gè)步驟順利的話你會(huì)看到一條消息從生產(chǎn)到消費(fèi)的全過(guò)程?，F(xiàn)場(chǎng)很多第一次摸 Pulsar 的朋友在這一步就消除了陌生感原來(lái)消息隊(duì)列的體驗(yàn)可以這么輕。之后再用pulsar-admin topics stats看 topic 的詳細(xì)統(tǒng)計(jì)就能直觀理解消息隊(duì)列的內(nèi)部狀態(tài)長(zhǎng)什么樣。3.2 用 Pulsar Operator 在 Kind 里部署集群Docker Compose 適合體驗(yàn)但如果你關(guān)注的是 K8s 環(huán)境下的真實(shí)運(yùn)維那一定得試試 Pulsar Operator。在實(shí)驗(yàn)區(qū)我們通過(guò) Kind 創(chuàng)建了一個(gè)包含一個(gè)控制平面和三個(gè)工作節(jié)點(diǎn)的集群然后安裝證書管理器、Pulsar Operator再提交一個(gè)自定義資源。核心操作大致如下kind create cluster --name pulsar-demo --config - EOF kind: Cluster apiVersion: kind.x-k8s.io/v1alpha4 nodes: - role: control-plane - role: worker - role: worker - role: worker EOF部署 Operator 后創(chuàng)建一個(gè)PulsarCluster資源apiVersion: pulsar.apache.org/v1alpha1 kind: PulsarCluster metadata: name: demo-pulsar spec: broker: replicas: 3 image: apachepulsar/pulsar:4.0.0 bookkeeper: replicas: 3 image: apachepulsar/pulsar:4.0.0 volumes: - name: data emptyDir: {}等 Pod 都變成 Running 后把 Broker 服務(wù)端口轉(zhuǎn)發(fā)出來(lái)接上文同樣的pulsar-client命令就能訪問(wèn)?，F(xiàn)場(chǎng)有人問(wèn)為什么不用emptyDir來(lái)做生產(chǎn)環(huán)境答案顯然是演示環(huán)境不在乎數(shù)據(jù)持久化生產(chǎn)環(huán)境一定會(huì)用 PVC 掛獨(dú)立存儲(chǔ)卷。這里想提醒大家Operator 只是把繁瑣的部署邏輯封裝了但它不會(huì)替你決定存儲(chǔ)方案網(wǎng)絡(luò)策略資源配額這些依然要按生產(chǎn)標(biāo)準(zhǔn)來(lái)設(shè)計(jì)。3.3 性能驗(yàn)證小規(guī)模也能看出架構(gòu)差異動(dòng)手實(shí)驗(yàn)區(qū)給我最大的驚喜不是“能跑”而是能自己動(dòng)手做簡(jiǎn)單的壓測(cè)驗(yàn)證架構(gòu)行為。主辦方給每個(gè)小組發(fā)了腳本用 Pulsar 自帶的pulsar-perf工具進(jìn)行生產(chǎn)壓測(cè)。我在 3 個(gè) Broker 和 3 個(gè) BookKeeper 的小集群上跑了一組對(duì)比先只擴(kuò) Broker 節(jié)點(diǎn)保持 BookKeeper 不變發(fā)現(xiàn)生產(chǎn)吞吐能明顯上漲然后只擴(kuò) BookKeeper 節(jié)點(diǎn)但擴(kuò)大存儲(chǔ)吞吐能力和磁盤數(shù)量之后積壓消費(fèi)的恢復(fù)速度更快了。命令本身很簡(jiǎn)單docker exec -it pulsar bin/pulsar-perf produce -r 100000 -s 1024 -t persist://public/default/perf-topic現(xiàn)場(chǎng)跑出的吞吐是每秒鐘十幾萬(wàn)條消息單條消息 1KB客戶端和集群都在同一臺(tái)機(jī)器上。這個(gè)數(shù)字不算夸張但它驗(yàn)證了一個(gè)關(guān)鍵結(jié)論在存儲(chǔ)計(jì)算分離架構(gòu)下Broker 和存儲(chǔ)可以獨(dú)立調(diào)優(yōu)。對(duì)于做技術(shù)選型的人來(lái)說(shuō)這種可拆分性意味著預(yù)算可以花在真正需要的地方。我還試著調(diào)低了 BookKeeper 的寫入副本數(shù)從默認(rèn)的 3 降到 2生產(chǎn)延遲立刻下降但可用性也下降。這種親手體驗(yàn)比看任何 benchmark 圖都更能幫助你理解“副本數(shù)不是越多越好而是要在一致性、延遲和成本之間做權(quán)衡”。4. 社區(qū)圓桌與開(kāi)發(fā)者生態(tài)項(xiàng)目是代碼更是秩序4.1 從“用 Pulsar”到“改 Pulsar”的成長(zhǎng)路徑圓桌環(huán)節(jié)請(qǐng)了幾位長(zhǎng)期活躍的社區(qū)貢獻(xiàn)者其中一位分享了自己從用戶到提交者再到 PMC 成員的經(jīng)歷。他最早只是在公司里負(fù)責(zé)維護(hù) Pulsar 集群遇到一個(gè) 訂閱模式相關(guān)的 bug提了個(gè) issue后來(lái)被引導(dǎo)去修復(fù)一個(gè)較小的 broker 端并發(fā)問(wèn)題。過(guò)程并不神秘先去讀pulsar-broker模塊的代碼跑相關(guān)測(cè)試然后提交 PR。從第一個(gè) PR 到成為核心貢獻(xiàn)者他用了大約兩年。他提到一個(gè)很實(shí)用的建議新手貢獻(xiàn)者別一上來(lái)就選設(shè)計(jì)類的大 issue先從標(biāo)注good first issue的入手比如完善監(jiān)控指標(biāo)、修文檔、補(bǔ)測(cè)試用例。這類任務(wù)能讓你快速理解模塊邊界。Pulsar 社區(qū)里有一條不成文的規(guī)則一個(gè)補(bǔ)丁的價(jià)值不僅在于修復(fù)正確還在于你是否補(bǔ)充了清晰的測(cè)試和變更日志。社區(qū) Review discussions 會(huì)對(duì)代碼風(fēng)格、異常處理、性能影響摳得很細(xì)但不會(huì)對(duì)新人苛刻到勸退。這個(gè)環(huán)節(jié)對(duì)我這樣的普通用戶也很有啟發(fā)。參與開(kāi)源不只是為了刷簡(jiǎn)歷而是當(dāng)你真正理解了代碼邏輯之后你在排查生產(chǎn)故障時(shí)會(huì)有完全不同的直覺(jué)。我過(guò)去遇到 broker 內(nèi)存上漲第一反應(yīng)是加內(nèi)存后來(lái)才學(xué)會(huì)從緩存配置、訂閱積壓、Backlog 大小這些角度去排查而這些認(rèn)知正是通過(guò)讀社區(qū)代碼和討論學(xué)到的。4.2 用戶案例車聯(lián)網(wǎng)、量化交易與 AI Agent社區(qū)圓桌之后是幾個(gè)真實(shí)用戶案例的閃電分享。第一個(gè)案例來(lái)自智能汽車行業(yè)車端設(shè)備通過(guò) MQTT 接入 Pulsar每天產(chǎn)生數(shù)億條車輛狀態(tài)事件包括電池SOC、定位、告警、OTA升級(jí)狀態(tài)。他們的需求很典型不同生命周期的事件有不同的優(yōu)先級(jí)車輛實(shí)時(shí)告警需要秒級(jí)投遞而歷史軌跡數(shù)據(jù)需要長(zhǎng)期保留用于模型訓(xùn)練。Pulsar 的多協(xié)議和分層存儲(chǔ)正好命中這兩個(gè)需求一套集群同時(shí)處理在線和離線鏈路。另一個(gè)案例讓我印象很深是一家量化交易團(tuán)隊(duì)。他們的消息系統(tǒng)不僅要快還要在極端行情下不能丟消息。該團(tuán)隊(duì)用 Pulsar 做訂單事件和行情數(shù)據(jù)的異步分發(fā)頻率不算高但每條消息都價(jià)值巨大。他們重點(diǎn)用到了 Pulsar 的事務(wù)消息能力和精確一次語(yǔ)義并定制了 Broker 的線程模型參數(shù)把端到端延遲控制在個(gè)位數(shù)毫秒級(jí)別。這個(gè)案例說(shuō)明MQ 在某些場(chǎng)景下不是“盡力而為”的工具而是必須能提供強(qiáng)保證的分布式基礎(chǔ)設(shè)施。AI Agent 場(chǎng)景被多次提及很有意思。Agent 需要同時(shí)維護(hù)多個(gè)外部工具調(diào)用和多個(gè)會(huì)話上下文相當(dāng)于一個(gè)復(fù)雜的異步并發(fā)系統(tǒng)。Pulsar 在這里被用作事件總線記錄 Agent 的每次決策、工具執(zhí)行結(jié)果和用戶反饋。這種數(shù)據(jù)天然是流式的需要支持回溯、重放和按時(shí)間線消費(fèi)。相比傳統(tǒng)“應(yīng)用日志 搜索存儲(chǔ)”的方案消息隊(duì)列給 AI 應(yīng)用提供了一種更結(jié)構(gòu)化、更可靠的事件基礎(chǔ)設(shè)施?？梢灶A(yù)見(jiàn) 2026 年會(huì)有更多 AI Infra 團(tuán)隊(duì)把 Pulsar 納入技術(shù)棧。5. 常見(jiàn)問(wèn)題與答疑實(shí)錄現(xiàn)場(chǎng)高頻問(wèn)題整理5.1 消息積壓、重復(fù)消費(fèi)與順序性現(xiàn)場(chǎng)答疑環(huán)節(jié)高頻問(wèn)題仍然圍繞消息隊(duì)列“老三樣”積壓怎么辦、重復(fù)消息怎么處理、順序性怎么保證。有位朋友問(wèn)“積壓幾百萬(wàn)條消息能不能直接把分區(qū)數(shù)調(diào)大來(lái)加速消費(fèi)”這個(gè)問(wèn)題很典型。Pulsar 的分區(qū)擴(kuò)容方式與 Kafka 相似擴(kuò)容之后通過(guò)增加消費(fèi)者并發(fā)確實(shí)能提升吞吐但積壓不只是消費(fèi)端并發(fā)問(wèn)題還要看下游系統(tǒng)能不能扛住壓力。我的建議一直是優(yōu)先確認(rèn) Backlog 是否已經(jīng)觸發(fā) Retention 策略避免數(shù)據(jù)被清理然后通過(guò)監(jiān)控看是消費(fèi)者處理慢還是 Broker 分發(fā)有瓶頸。Pulsar 提供了比較完善的 Backlog 指標(biāo)也可以用pulsar-admin topics stats查看每個(gè)訂閱的msgBacklog和blockedSubscriptionOnUnackedMessages。如果是因?yàn)橄掠翁幚砟芰Σ蛔忝つ考酉M(fèi)者只會(huì)把下游壓垮。更穩(wěn)妥的方式是先擴(kuò)容下游再逐步增加消費(fèi)者實(shí)例并配合按累計(jì)積壓量自動(dòng)伸縮的機(jī)制。重復(fù)消費(fèi)這個(gè)問(wèn)題Pulsar 可以從兩個(gè)層面回答消息確認(rèn)語(yǔ)義支持最多一次、至少一次和精確一次事務(wù)消息能保證一批消息的原子性寫入但對(duì)下游來(lái)說(shuō)仍然建議在消費(fèi)者里做冪等設(shè)計(jì)。順序性則要按需取舍Pulsar 支持按 key 哈希到單個(gè)分區(qū)來(lái)保證同一 key 的消息順序但這會(huì)損失單個(gè)分區(qū)的寫入并行度。沒(méi)有任何消息系統(tǒng)能在“全局順序、無(wú)限并行、高性能”三個(gè)維度同時(shí)拉滿必須在建模階段想清楚需求邊界。5.2 集群運(yùn)維元數(shù)據(jù)存儲(chǔ)、故障替換與版本升級(jí)很多人關(guān)心 Pulsar 依賴 ZooKeeper 或 etcd 做元數(shù)據(jù)存儲(chǔ)這件事。在 4.x 時(shí)代Pulsar 默認(rèn)還會(huì)使用 ZooKeeper但社區(qū)正在推動(dòng)用 etcd 作為替代減少外部依賴。現(xiàn)場(chǎng)運(yùn)維專家建議生產(chǎn)環(huán)境不要把元數(shù)據(jù)服務(wù)和其他業(yè)務(wù)混部并確保定期備份。雖然元數(shù)據(jù)量不大但一旦損壞整個(gè)集群的服務(wù)發(fā)現(xiàn)和主題元數(shù)據(jù)都會(huì)受影響。版本升級(jí)是另一個(gè)高頻問(wèn)題。Pulsar 的版本迭代比較快跨大版本升級(jí)時(shí)要注意 broker 與 bookkeeper 之間的兼容性。社區(qū)給出的經(jīng)驗(yàn)是升級(jí)前先閱讀 release notes尤其是配置項(xiàng)變更和移除項(xiàng)然后用金絲雀升級(jí)的方式先升級(jí)一個(gè) broker 觀察穩(wěn)定再逐步推進(jìn)。BookKeeper 的升級(jí)通常需要滾動(dòng)重啟但 Pulsar 可以做到不停機(jī)前提是讀寫在升級(jí)過(guò)程中不能關(guān)。很多升級(jí)事故都出在順序上比如先升級(jí)了 ZooKeeper 又回到舊版這種來(lái)回橫跳很容易造成 meta 信息不兼容。現(xiàn)場(chǎng)也有人問(wèn)“能不能直接從一個(gè) Kafka 集群平滑遷移到 Pulsar”。答案是可以做但過(guò)程需要規(guī)劃。比較推薦的路徑是先用 Pulsar 的 Kafka 協(xié)議兼容層讓新集群“偽裝”成 Kafka endpoint然后通過(guò)雙寫切換最后再裁剪舊集群。這套方案的核心收益是遷移過(guò)程中不需要修改客戶端代碼也不需要對(duì)生產(chǎn)流量做激進(jìn)的割接。6. 一些會(huì)后想補(bǔ)充的個(gè)人經(jīng)驗(yàn)活動(dòng)結(jié)束后我又花了兩天時(shí)間在自己本地環(huán)境里復(fù)現(xiàn)了動(dòng)手實(shí)驗(yàn)中的主要操作順便測(cè)試了幾個(gè)現(xiàn)場(chǎng)來(lái)不及做的功能。這里想分享一個(gè)很小的經(jīng)驗(yàn)很多人看到 Pulsar 的組件清單Broker、BookKeeper、ZooKeeper、Proxy會(huì)覺(jué)得很重但實(shí)際上跑一個(gè)開(kāi)發(fā)測(cè)試環(huán)境遠(yuǎn)比想象中輕。官方 Docker 鏡像里標(biāo)準(zhǔn)包已經(jīng)自動(dòng)完成了配置組裝甚至連pulsar standalone這樣的命令都幫你把元數(shù)據(jù)服務(wù)一并拉起了。真正值得花時(shí)間研究的不是“怎么啟動(dòng)”而是“生產(chǎn)環(huán)境里如何把每個(gè)組件的職責(zé)邊界劃清楚”。另一個(gè)體會(huì)是消息中間件這個(gè)領(lǐng)域其實(shí)特別需要“場(chǎng)景驅(qū)動(dòng)”的學(xué)習(xí)方式。只看架構(gòu)圖、只對(duì)著文檔調(diào)參很難真正理解為什么存儲(chǔ)計(jì)算分離有意義。我建議你先從自己的業(yè)務(wù)出發(fā)找一個(gè)痛點(diǎn)比如“歷史消息無(wú)法回溯”“擴(kuò)容總需要搬遷數(shù)據(jù)”“多個(gè)協(xié)議客戶端無(wú)法統(tǒng)一接入”然后帶著問(wèn)題去 Pulsar 文檔里找答案。你會(huì)發(fā)現(xiàn)自己對(duì)消息系統(tǒng)的理解會(huì)從“會(huì)用一個(gè)工具”變成“能設(shè)計(jì)一套消息基礎(chǔ)設(shè)施”。最后再分享一件小事。圓桌結(jié)尾有觀眾問(wèn)“Pulsar 社區(qū)未來(lái)一年最希望看到什么變化”一位維護(hù)者想了想說(shuō)“希望更多新場(chǎng)景的人來(lái)‘折騰’我們而不是只要求我們變得更像老牌 MQ?！边@句話讓我挺觸動(dòng)的。消息隊(duì)列從來(lái)不應(yīng)該是保守的代名詞它值得在新架構(gòu)、新場(chǎng)景里被重新發(fā)明一遍。如果你也在關(guān)注 MQ 的演進(jìn)希望這篇回顧能讓你感受到下一次技術(shù)選型時(shí)除了“用哪個(gè)老牌中間件”我們還可以有更多值得認(rèn)真評(píng)估的選項(xiàng)。