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

作者 | 王任義 360 云平臺，基礎架構部消息中間件研發

“我們運維上百套裸金屬 Kafka 集群多年，最頭疼的就是業務高峰期消費積壓拖垮整個集群的寫入。切換到 AutoMQ 后，日志檢索平臺的生產 P99 從 10 秒降到 500 毫秒，積壓量下降了 40 倍，硬件成本還節省了一半。現在團隊終于可以把精力從基礎設施運維轉向業務優化。”

1 關于 360：從安全到云原生基礎設施

360 集團是中國領先的互聯網安全公司，也是互聯網免費安全的倡導者和先行者。自 2005 年創立以來，先后推出 360 安全衛士、360 手機衛士、360 安全瀏覽器等安全產品，服務數億用戶。隨著業務版圖從安全延伸到搜索、游戲、智能硬件等領域，360 內部的數據規模也在持續膨脹——每天產生千億級日志，PB 級數據需要實時采集、傳輸和分析。

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

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

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

2 冷 讀：從 Kafka 的架構短板到 AutoMQ 的解法

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

問題的根源在于 Kafka 讀寫路徑上的兩個關鍵技術選擇：

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

第二，SendFile 系統調用阻塞網絡線程。 Kafka 的零拷貝機制依賴 SendFile 系統調用，而這個調用發生在 Kafka 的網絡線程池中。當 SendFile 需要從磁盤拷貝冷數據時，會阻塞網絡線程。由于同一個線程池同時處理讀寫請求，冷讀不僅拖慢自己，還會級聯影響同集群所有 Topic 的寫入性能。

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

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

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

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

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

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

3 性能評估與驗證

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

性能基準測試

評估環境就緒后，第一步是驗證基礎延遲是否滿足生產要求。團隊在 8 節點 Broker 集群上，使用業界標準的 OpenMessaging Benchmark 框架，分別以 100 MiB/s 和 500 MiB/s 兩個負載級別進行壓測（acks=all，確保數據持久化后再返回成功）：

• 發送延遲（ms）

• 端到端延遲（ms）

追趕讀隔離測試

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

彈性伸縮測試

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

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

相比傳統 Kafka 擴容動輒數小時的數據遷移，這個結果意味著 360 未來面對突發流量時，可以真正實現自動化的彈性響應，而不再依賴人工值守和提前預留大量冗余資源。

評估結論

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

4 生產部署與收益

基于評估結果，360 團隊決定將日志檢索平臺——冷讀問題最突出的業務——作為第一個生產業務切換到 AutoMQ。

生產部署架構

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

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

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

上線收益

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

Kafka 常被用于削峰填谷，消息堆積本身是正常現象，關鍵在于消費者能否快速消化這些積壓數據。Apache Kafka 的傳統架構下，冷讀會觸發 Broker 磁盤 I/O，顯著拖慢消費速率。

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

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

存儲方面，數據自動持久化到對象存儲，存儲容量隨業務量彈性增長，無需提前規劃磁盤容量，也不再有裸金屬時代磁盤空間告警的運維負擔。

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

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

切換 AutoMQ 前的 Consumer Lag

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

5 展 望

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