360 如何用 AutoMQ 解決千億級 Kafka 冷讀難題

作者 | 王任義 360 云平臺，基礎(chǔ)架構(gòu)部消息中間件研發(fā)

“我們運維上百套裸金屬 Kafka 集群多年，最頭疼的就是業(yè)務(wù)高峰期消費積壓拖垮整個集群的寫入。切換到 AutoMQ 后，日志檢索平臺的生產(chǎn) P99 從 10 秒降到 500 毫秒，積壓量下降了 40 倍，硬件成本還節(jié)省了一半?，F(xiàn)在團(tuán)隊終于可以把精力從基礎(chǔ)設(shè)施運維轉(zhuǎn)向業(yè)務(wù)優(yōu)化?！?/p>

1 關(guān)于 360：從安全到云原生基礎(chǔ)設(shè)施

360 集團(tuán)是中國領(lǐng)先的互聯(lián)網(wǎng)安全公司，也是互聯(lián)網(wǎng)免費安全的倡導(dǎo)者和先行者。自 2005 年創(chuàng)立以來，先后推出 360 安全衛(wèi)士、360 手機(jī)衛(wèi)士、360 安全瀏覽器等安全產(chǎn)品，服務(wù)數(shù)億用戶。隨著業(yè)務(wù)版圖從安全延伸到搜索、游戲、智能硬件等領(lǐng)域，360 內(nèi)部的數(shù)據(jù)規(guī)模也在持續(xù)膨脹——每天產(chǎn)生千億級日志，PB 級數(shù)據(jù)需要實時采集、傳輸和分析。

支撐這一切的底座，是360 云平臺。作為集團(tuán)技術(shù)中臺，360 云平臺為所有業(yè)務(wù)線提供存儲、計算、中間件等基礎(chǔ)云服務(wù)，而 Kafka 是其中最核心的消息隊列中間件。生產(chǎn)環(huán)境運行著上百套 Kafka 集群，主要采用裸金屬部署，單 Topic 峰值 60 萬 QPS，集群峰值 500 萬 QPS。

隨著集群規(guī)模持續(xù)增長，運維成本和隔離性問題日益突出——硬件故障處理、擴(kuò)容遷移、追趕讀拖垮寫入，這些都是大規(guī)模裸金屬 Kafka 的老大難問題。在云原生和 Serverless 的大趨勢下，360 云平臺開始思考：是否有更先進(jìn)的 Kafka 架構(gòu)，能更好地適配云時代？

團(tuán)隊開始調(diào)研新一代方案，AutoMQ 基于 S3 的 Diskless Kafka 架構(gòu)引起了關(guān)注——存算分離、讀寫路徑隔離、秒級彈性伸縮，這些特性恰好對準(zhǔn)了 360 在大規(guī)模 Kafka 運維中最頭疼的問題。而 360 內(nèi)部團(tuán)隊基于 Apache OZone 提供了支持 S3 API 標(biāo)準(zhǔn)協(xié)議的分布式存儲系統(tǒng)，意味著 AutoMQ 所需的對象存儲底座在 360 內(nèi)部已經(jīng)具備，落地條件成熟。

2 冷 讀：從 Kafka 的架構(gòu)短板到 AutoMQ 的解法

追趕讀（catch-up read）是消息系統(tǒng)中非常常見的場景：下游消費者因為處理瓶頸或批處理任務(wù)，需要從較早的位點開始消費已經(jīng)不在內(nèi)存中的“冷數(shù)據(jù)”。對于大多數(shù)消息系統(tǒng)來說，這本不應(yīng)該是個難題，但 Apache Kafka 的架構(gòu)設(shè)計讓冷讀變成了一個影響全局的性能殺手。

問題的根源在于 Kafka 讀寫路徑上的兩個關(guān)鍵技術(shù)選擇：

第一，Page Cache 無法區(qū)分冷熱數(shù)據(jù)。 Kafka 將內(nèi)存管理完全交給操作系統(tǒng)的 Page Cache，自身不做冷熱分離。當(dāng)消費者讀取冷數(shù)據(jù)時，大量磁盤數(shù)據(jù)被加載進(jìn) Page Cache，擠占了熱數(shù)據(jù)的內(nèi)存空間，導(dǎo)致原本可以從內(nèi)存直接讀取的實時消費（tail read）也開始頻繁觸發(fā)磁盤 IO。

第二，SendFile 系統(tǒng)調(diào)用阻塞網(wǎng)絡(luò)線程。 Kafka 的零拷貝機(jī)制依賴 SendFile 系統(tǒng)調(diào)用，而這個調(diào)用發(fā)生在 Kafka 的網(wǎng)絡(luò)線程池中。當(dāng) SendFile 需要從磁盤拷貝冷數(shù)據(jù)時，會阻塞網(wǎng)絡(luò)線程。由于同一個線程池同時處理讀寫請求，冷讀不僅拖慢自己，還會級聯(lián)影響同集群所有 Topic 的寫入性能。

這是一個已知的架構(gòu)問題（KAFKA-7504），至今未被根本解決。

https://issues.apache.org/jira/browse/KAFKA-7504

360 云平臺對此深有體感。360 有一個核心業(yè)務(wù)場景：線上服務(wù)的統(tǒng)一日志檢索平臺，所有服務(wù)的運行日志通過 Kafka 收集，統(tǒng)一寫入 Elasticsearch，業(yè)務(wù)基于 ES 做日志檢索和告警。這個業(yè)務(wù)的特點是波峰波谷明顯——每天業(yè)務(wù)高峰期，下游 ES 寫入達(dá)到瓶頸，消費者跟不上生產(chǎn)者，消息開始積壓，正是上面描述的冷讀場景。實際表現(xiàn)：業(yè)務(wù)高峰期消息積壓達(dá)到 10 億條、約 200 GB，集群寫入 P99 飆升到約 10 秒，同集群內(nèi)其他業(yè)務(wù)的 Topic 也受到影響，日志檢索和告警的及時性無法保障。

AutoMQ 從架構(gòu)設(shè)計的第一天就考慮了冷熱數(shù)據(jù)隔離問題，將數(shù)據(jù)路徑拆分為三條獨立通道：

寫入使用 Direct IO 繞過 Page Cache，從根本上避免了冷讀對寫入路徑的干擾。冷讀走對象存儲的高吞吐通道，充分利用對象存儲的帶寬能力，不與寫入和實時消費爭搶資源。三條路徑在架構(gòu)層面徹底隔離，意味著無論下游消費者積壓多少數(shù)據(jù)，追趕讀都不會影響生產(chǎn)者的寫入性能。

對 360 來說，AutoMQ 的三路徑架構(gòu)直接對應(yīng)了日志檢索平臺面臨的冷讀問題。同時，AutoMQ 100% 兼容 Kafka 協(xié)議，360 已有的業(yè)務(wù)代碼和自研 Client 框架無需改造；云原生的 K8s 部署模式也與 360 云平臺已全面容器化的基礎(chǔ)設(shè)施天然契合。

3 性能評估與驗證

在正式投入生產(chǎn)之前，360 團(tuán)隊在 Kubernetes 上搭建了評估集群，從基礎(chǔ)延遲、冷讀隔離、彈性伸縮三個維度對 AutoMQ 進(jìn)行了系統(tǒng)性驗證。評估集群使用 StatefulSet 分別管理 AutoMQ 的 Controller（2C/4GB）和 Broker（4C/16GB），數(shù)據(jù)持久化到對象存儲。

性能基準(zhǔn)測試

評估環(huán)境就緒后，第一步是驗證基礎(chǔ)延遲是否滿足生產(chǎn)要求。團(tuán)隊在 8 節(jié)點 Broker 集群上，使用業(yè)界標(biāo)準(zhǔn)的 OpenMessaging Benchmark 框架，分別以 100 MiB/s 和 500 MiB/s 兩個負(fù)載級別進(jìn)行壓測（acks=all，確保數(shù)據(jù)持久化后再返回成功）：

• 發(fā)送延遲（ms）

• 端到端延遲（ms）

追趕讀隔離測試

團(tuán)隊以 100 MiB/s 持續(xù)發(fā)送，在累積 100 GiB 數(shù)據(jù)后拉起消費者從最早位點開始消費，模擬業(yè)務(wù)高峰期的冷讀場景。結(jié)果表明：寫入速率和延遲在追趕讀期間保持穩(wěn)定，追趕讀峰值達(dá)到約 461 MiB/s，能夠快速消化積壓消息。讀寫路徑的隔離性得到驗證。

彈性伸縮測試

對于 360 這樣擁有上百套 Kafka 集群的團(tuán)隊來說，彈性伸縮能力直接決定了運維負(fù)擔(dān)的大小。傳統(tǒng) Apache Kafka 的擴(kuò)容之所以慢，根本原因在于 Broker 是有狀態(tài)的——每個 Broker 本地磁盤上存儲著大量 partition 數(shù)據(jù)，新增節(jié)點后需要跨網(wǎng)絡(luò)遷移這些數(shù)據(jù)才能實現(xiàn)負(fù)載均衡，數(shù)據(jù)量越大遷移越慢，動輒數(shù)小時甚至數(shù)天。AutoMQ 的存算分離架構(gòu)從根本上改變了這一點：數(shù)據(jù)全部持久化在對象存儲中，Broker 是無狀態(tài)的，新節(jié)點啟動后只需接管 partition 的元數(shù)據(jù)，無需遷移任何數(shù)據(jù)，因此可以做到秒級分區(qū)遷移和分鐘級彈性擴(kuò)容。擴(kuò)容完成后，AutoMQ 內(nèi)置的自動重平衡機(jī)制會持續(xù)監(jiān)測各節(jié)點負(fù)載，動態(tài)調(diào)度分區(qū)分配，確保流量在新舊節(jié)點間自動均衡。

360 團(tuán)隊設(shè)計了一個極端場景來驗證這一能力：集群初始只有 1 個 Broker，創(chuàng)建 1000 分區(qū)的 Topic，直接以 1 GiB/s 的流量發(fā)送。從監(jiān)控告警觸發(fā)到批量擴(kuò)容再到流量自動均衡，全程 4 分鐘完成，無需人工干預(yù)，實際驗證效果如下圖所示。

相比傳統(tǒng) Kafka 擴(kuò)容動輒數(shù)小時的數(shù)據(jù)遷移，這個結(jié)果意味著 360 未來面對突發(fā)流量時，可以真正實現(xiàn)自動化的彈性響應(yīng)，而不再依賴人工值守和提前預(yù)留大量冗余資源。

評估結(jié)論

三輪測試全部符合預(yù)期?；A(chǔ)延遲在 acks=all 配置下依然保持毫秒級；追趕讀期間寫入性能完全不受影響，冷熱隔離的架構(gòu)承諾得到了實測驗證；彈性伸縮從 0 到 1 GiB/s 僅需 4 分鐘，徹底改變了傳統(tǒng) Kafka 擴(kuò)容的運維模式。

4 生產(chǎn)部署與收益

基于評估結(jié)果，360 團(tuán)隊決定將日志檢索平臺——冷讀問題最突出的業(yè)務(wù)——作為第一個生產(chǎn)業(yè)務(wù)切換到 AutoMQ。

生產(chǎn)部署架構(gòu)

生產(chǎn)環(huán)境沿用了評估階段的部署模式。AutoMQ 的架構(gòu)設(shè)計理念是將數(shù)據(jù)持久性和可用性卸載給云存儲，對象存儲本身的高可用性是整個架構(gòu)的基石。為了在此基礎(chǔ)上進(jìn)一步提升可用性，360 額外設(shè)計了集群級故障切換方案。

360 的做法是：每個 AutoMQ 集群配備一個 HA 備用集群，定時同步集群元數(shù)據(jù)。生產(chǎn)集群通過實時寫檢測持續(xù)監(jiān)控健康狀態(tài)，一旦檢測到異常，自動將集群 DNS 解析切換到備用集群，同時修改 Endpoint 服務(wù)返回的集群地址?？蛻舳藗?cè)配置 metadata.recovery.strategy=rebootstrap (Kafka KIP-899)，故障發(fā)生后客戶端自動重新初始化連接地址完成集群切換，備用集群按需彈性擴(kuò)容承接流量。這套方案充分利用了 AutoMQ Broker 無狀態(tài)的特性——備用集群無需預(yù)先承載數(shù)據(jù)，只需在切換時快速擴(kuò)容即可。

在資源配置上，單個日志檢索集群高峰期部署 30 個 Broker Pod（4C/16GB），配合 HPA 自動伸縮，低峰期自動縮容節(jié)省資源。相比此前裸金屬 Kafka 需要長期預(yù)留大量物理機(jī)應(yīng)對峰值流量，容器化部署的資源利用率有了質(zhì)的提升。

上線收益

日志檢索平臺切換到 AutoMQ 后，困擾團(tuán)隊已久的業(yè)務(wù)高峰期消息積壓問題被徹底解決。下表對比了切換前后積壓數(shù)據(jù)處理的核心指標(biāo)，可以看到 AutoMQ 顯著提升了 Kafka 生產(chǎn)消費鏈路在消息堆積場景下的處理效率。

Kafka 常被用于削峰填谷，消息堆積本身是正常現(xiàn)象，關(guān)鍵在于消費者能否快速消化這些積壓數(shù)據(jù)。Apache Kafka 的傳統(tǒng)架構(gòu)下，冷讀會觸發(fā) Broker 磁盤 I/O，顯著拖慢消費速率。

AutoMQ 采用 Diskless 架構(gòu)，天然實現(xiàn)冷熱數(shù)據(jù)分離：冷讀時通過 prefetch 和并發(fā)優(yōu)化直接從對象存儲拉取歷史數(shù)據(jù)，既不影響實時寫入和追尾讀，也不會引發(fā) Broker 側(cè)的磁盤 I/O 和性能劣化，因此能夠顯著提升積壓數(shù)據(jù)的消費速率，避免流量高峰期間堆積過多的數(shù)據(jù)。

從吞吐監(jiān)控可以看到，切換后的日志檢索集群在業(yè)務(wù)高峰期峰值吞吐達(dá)到 1.4 GB/s，30 個 4C/16GB 的 Pod 即可穩(wěn)定承載，寫入曲線平滑無毛刺。

存儲方面，數(shù)據(jù)自動持久化到對象存儲，存儲容量隨業(yè)務(wù)量彈性增長，無需提前規(guī)劃磁盤容量，也不再有裸金屬時代磁盤空間告警的運維負(fù)擔(dān)。

對比最為直觀的是 Consumer Lag 曲線：切換前，業(yè)務(wù)高峰期積壓峰值超過 10 億條消息；切換后，同樣的業(yè)務(wù)流量下積壓量下降了 40 倍，消費者能夠快速追上生產(chǎn)進(jìn)度。

其中最關(guān)鍵的變化是隔離性：切換前，業(yè)務(wù)高峰期的消息積壓會通過冷讀污染 Page Cache，級聯(lián)拖垮同集群所有 Topic 的寫入；切換后，由于 AutoMQ 的讀寫路徑在架構(gòu)層面徹底隔離，即使下游 ES 出現(xiàn)寫入瓶頸導(dǎo)致消費積壓，生產(chǎn)端的寫入延遲依然保持在毫秒級，日志檢索和告警的及時性得到保障。

切換 AutoMQ 前的 Consumer Lag

切換 AutoMQ 后的 Consumer Lag (積壓下降 40 倍)

5 展 望

日志檢索平臺的上線驗證了 AutoMQ 在 360 生產(chǎn)環(huán)境中的可行性。作為集團(tuán)技術(shù)中臺，360 云平臺承載著上百套 Kafka 集群，覆蓋日志采集、實時計算、監(jiān)控告警、數(shù)據(jù)同步等多種業(yè)務(wù)場景。日志檢索平臺只是第一步，接下來團(tuán)隊計劃將 AutoMQ 逐步推廣到更多業(yè)務(wù)線的 Kafka 集群，充分利用存算分離架構(gòu)帶來的彈性伸縮和成本優(yōu)勢，最終實現(xiàn)從裸金屬到云原生 Kafka 架構(gòu)的整體升級。