Apache Pulsar 是 Apache 軟件基金會頂級項目，是下一代云原生分布式消息流平臺，集消息、存儲、輕量化函數(shù)式計算為一體。該系統(tǒng)源于 Yahoo，最初在 Yahoo 內部開發(fā)和部署，支持 Yahoo 應用服務平臺 140 萬個主題，日處理超過 1000 億條消息。Pulsar 于 2017 年由 Yahoo 開源并捐贈給 Apache 軟件基金會進行孵化，2018 年成為 Apache 軟件基金會頂級項目。

滴滴大數(shù)據(jù)于 2021 年 01 月開始調研 Pulsar ，建立內部 Pulsar 2.7 版本分支；并于 2021 年 08 月 04 日，正式上線了第一個 Pulsar 數(shù)據(jù)通道同步任務集群，主要為數(shù)據(jù)開發(fā)平臺-同步中心產品提供服務，涉及 Log->ES、BamaiLog->ES、BamaiLog->CK、Log->HDFS 鏈路。截止目前，已穩(wěn)定運行兩年有余。

引入 Pulsar 的收益

滴滴大數(shù)據(jù) DKafka 集群，基于社區(qū) 2.12-0.10.2.0 版本。在運維過程中，遇到了不少痛點，如磁盤 IO 不均、存儲容量不均、CPU 利用率不均等負載不均問題，尤其是在高峰期出現(xiàn)瓶頸或故障發(fā)生后，想要快速擴容止損成為了一個棘手的問題。盡管團隊已經在自動化運維方面做出了不少努力，比如實施了根據(jù)磁盤 IO 負載自動調整分區(qū)、批量自動遷移計劃、以及存儲自動負載均衡等措施，但仍需耗費大量的人力來維護這個重度運維的系統(tǒng)。

Pulsar 的出現(xiàn)，為滴滴大數(shù)據(jù)消息系統(tǒng)帶來了新的可能性。特別是對于當前我們所遇到的痛點，Pulsar 提供了一些優(yōu)雅的解決方案。

解決 SATA HDD 盤的磁盤 IO 瓶頸問題

DKafka 采用分段式 appendlog 順序寫入方式，將分區(qū)消息落盤。但是當 Broker 上有成百上千個 topic partition 時，由于需要切換分區(qū)消息寫入到對應分區(qū) log 文件，從磁盤角度看就變回了隨機寫入，磁盤讀寫性能將會隨著 Broker 上 topic partition 數(shù)量的增加而降低，用戶感知現(xiàn)象為生產/拉取耗時增漲。

DKafka 集群運維管理員接不完的 io 熱點報警

Pulsar 存算分離架構，存儲層 Bookie 在存儲數(shù)據(jù)時，通過將不同分區(qū)的消息在內存中排序后定期順序刷盤到同一個entrylog 文件中，再通過 rocksdb 索引組織 entrylog 中的消息與分區(qū) segment 的映射關系，解決隨機寫入問題。因此 Pulsar 號稱可以支持百萬分區(qū)，不會因為隨機寫而導致性能急劇下降。

解決集群容量瓶頸問題

針對 DKafka 集群中存在的 IO 瓶頸問題，數(shù)據(jù)通道團隊自2020年至2021年間對線上集群進行了 SSD 機型置換。然而，除部分集群間的數(shù)據(jù)同步極端場景外，如磁盤故障后拉起服務，仍可能出現(xiàn)大量消息落盤行為集中在一臺硬盤上的情況?？紤]到 SSD 成本較高，團隊決定降低集群存儲容量，導致集群不再滿足原有的3副本36小時存儲周期要求。經過調研用戶需求，團隊決定將副本數(shù)調整為2，并將存儲周期改為24小時，以滿足大多數(shù)用戶的需求。對于仍需更長存儲周期的用戶，可由用戶發(fā)起申請，SRE 協(xié)助單獨調整存儲周期。盡管如此，仍然存在大量的磁盤熱點/單機熱點，需要 DKafka 集群運維管理員進行負載均衡。

DKafka 集群中多塊盤存儲容量達到瓶頸

由于 Pulsar 存儲層在存儲數(shù)據(jù)時，一定是順序存儲的，所以 Pulsar 機型在選型時，可以選擇大容量 SATA HDD 盤 + NVME 異構機型，NVME 盤主要作為存儲層 journal 和存儲層 index 即內嵌 rocksdb 的存儲介質。參照原 DKafka 的全 SSD 數(shù)據(jù)盤機型，Pulsar 存儲異構機型，在降低成本的情況下，還能延長存儲周期，增加副本數(shù)。

解決緩存 / IO 未隔離問題

在使用 DKafka 的過程中，重置 topic 的消費組 offset 是常見操作，但這會導致磁盤讀取增加，進而加重磁盤 IO 的工作負載。由于 DKafka 的 IO 沒有隔離，因此讀取操作也會影響寫入，從而導致讀寫耗時顯著增長。此外，集群的擴容、縮容以及磁盤故障后屏蔽故障盤數(shù)據(jù)目錄再上線的操作，也會對 pagecache 系統(tǒng)頁緩存造成污染，導致更多的讀消息 cache miss，進一步加重磁盤 IO 的工作負載。

DKafka 集群在數(shù)據(jù)遷移期間 p99 生產耗時受到顯著影響

Pulsar的多級緩存特性為其無狀態(tài)的計算層Broker將接收到的消息緩存在堆外內存中，同時這些消息也作為實時讀緩存。當Broker中的cache miss發(fā)生時，會觸發(fā)存儲層的讀取。存儲層Bookie設計了多級緩存，包括只讀的寫緩存和讀寫的寫緩存（后者寫滿時會觸發(fā)切換）。如果這兩塊緩存都miss了，就會到讀緩存中讀取，如果讀緩存也miss了，才會觸發(fā)磁盤讀取。磁盤讀取完成后，會觸發(fā)預讀，預讀的消息會被緩存在讀緩存中。

?Pulsar 多級緩存，綠色為命中緩存，黃色虛線為分區(qū)連續(xù)追趕讀的第一次 cache miss 進行磁盤預讀

（圖片來源 Pulsar 社區(qū)）

Pulsar 存儲層 IO 隔離

（圖片來源 Pulsar 社區(qū)）

解決單盤/單機存儲熱點問題

DKafka 采用存算一體架構，分區(qū)與 Broker 緊密綁定，分區(qū)存儲的分段消息文件在沒有外部運維操作的情況下，與磁盤緊密綁定。此外，DKafka 在分配新建分區(qū)時，對磁盤相關指標的參考較少，僅排除存儲和 IO 熱點盤，且集群內部缺乏主動 rebalance 重調度分配分區(qū)的能力。這一問題可能導致集群中部分節(jié)點/節(jié)點中部分磁盤首先達到瓶頸，從而大幅增加運維難度。在容量評估時，也需要考慮這一特點，預留更多的 buffer。當集群中出現(xiàn)熱點瓶頸時，需要逐一分區(qū)遷移（集群級機器存儲熱點）或切分區(qū)分段消息文件的存儲目錄（機器級磁盤存儲熱點），甚至可能需要根據(jù)所有消費組的延遲臨時縮短 topic 存儲周期來解決，這需要投入大量人力進行負載均衡工作，降低出現(xiàn)熱點瓶頸的概率，提升集群利用率。如果集群中出現(xiàn)大面積消費延遲的情況，根據(jù)延遲進行縮短存儲周期的自愈工作將無法開展，還需要聯(lián)系用戶確認丟失的數(shù)據(jù)或進行生產限流，以避免磁盤寫滿。

DKafka 集群存在存儲熱點，部分數(shù)據(jù)盤達到報警閾值，觸發(fā)自愈，自動縮短占盤最大分區(qū)的 topic 存儲周期

使用現(xiàn)有遷移工具進行機器置換&擴容完成后存儲不均，需要再進行 region 內機器級存儲均衡

?DKafka 集群各塊盤存儲壓力嚴重不均

Pulsar 的存算組件都是節(jié)點對等的，計算層的 topic 分區(qū) segment 輪轉切 ensemble 的 ledger rollover 特性使得可以從集群中重新選擇存儲節(jié)點；存儲層則根據(jù) ledger id 放置 entrylog 的特性來重新選擇存儲盤。Pulsar 從架構上進行改善，天然地將數(shù)據(jù)分散到不同存儲節(jié)點中的不同數(shù)據(jù)目錄下，這使得存儲層 Bookie 集群基本上不需要人工干預存儲相關的數(shù)據(jù)均衡工作，集群中所有數(shù)據(jù)盤的存儲容量利用率差異基本控制在10%以內。值得一提的是，存儲層的 ensemble 機制還可以讓多副本的分區(qū)消息存儲在比副本數(shù)更多的機器上，例如（5,3,2）配置，這意味著計算層將從存儲層集群中選擇5個 Bookie 節(jié)點進行分段消息的存儲，每批 entry 會寫到3個 Bookie 中，只要等待2個 Bookie 返回 ack，計算層 Broker 就完成了消息寫入流程。

Pulsar 存算分離架構可實現(xiàn)將分段消息再進行分片存儲，打散到不同 Bookie 節(jié)點

（圖片來源 Pulsar 社區(qū)）

?Pulsar 集群各塊盤存儲壓力相對均衡

解決 topic 分區(qū)元數(shù)據(jù)多，rebalance 壓力大問題

DKafka 集群分區(qū)數(shù)據(jù)多時，分區(qū) leader rebalance 壓力大，線上因此發(fā)生過分區(qū)無 leader 的故障，需要重啟異常 Broker 和 controller 解決，對集群穩(wěn)定性是非常大的挑戰(zhàn)。

大量分區(qū) leader rebalance 對集群的影響

Pulsar 計算層 Broker 無狀態(tài)設計，可卸式的 topic 全集以哈希環(huán)的方式組成 bundle 集合；讓每個 namespace 中的百萬分區(qū)，通過有限個 bundle 提供服務（bundle 初始化數(shù)可控制，支持對半分裂），計算層 Broker 元數(shù)據(jù)大幅降低。

Pulsar 的每個 namespace 僅需要維護 hash 環(huán)上有限 個 bundle，大幅減少計算層元數(shù)據(jù)

（圖片來源 Pulsar 社區(qū)）

解決負載均衡復雜度高，需要投入較多人力運維問題

目前，線上規(guī)模最大的 DKafka 廣州 common 公共集群擁有 57485 個分區(qū)，但在有次護堤時出現(xiàn)了機器熱點，表現(xiàn)為部分機器 CPU 空閑率低、機器負載高和網卡打滿的情況。在這種情況下，集群并不會通過分區(qū)遷移來實現(xiàn)負載均衡和消除熱點機器，而是通過調整分區(qū) AR 順序，然后執(zhí)行分區(qū)優(yōu)選副本切換 Leader 的操作，將熱點機器上的分區(qū) Leader 切換到低負載的其他機器上，以此來緩解集群熱點對集群穩(wěn)定性的影響。然而，如何選擇熱點機器上的哪些分區(qū) Leader 進行切換是一項相對復雜的工作，需要根據(jù)導致熱點的指標，綜合考慮選擇流量高、消費組多、QPS 高、存儲周期長的 topic 分區(qū)列表，同時還需要考慮這些分區(qū)的 ISR 列表是否未同步，以及 ISR 列表中的其他 Broker 是否也是熱點機器；只有在這些條件都不滿足的情況下，才能進行分區(qū) Leader 切換操作。

相比之下，Pulsar 的 bundle 機制大大降低了負載均衡的復雜度。由于計算層 Broker 節(jié)點對等，Broker 之間無需主從同步，計算層 Broker 可以向存儲層 Bookie 進行條帶化多副本寫入。因此，計算層 Broker 的負載均衡只需要簡單地 unload 熱點機器上的 bundle，LeaderBroker 將會感知到沒有 owner 的 bundle，然后根據(jù)集群指標挑選最優(yōu) Broker 進行分配，即可完成將落在哈希環(huán)中由此 bundle 提供服務的大量分區(qū)，一鍵漂移到其他 Broker 上提供服務，從而大幅提升運維效率。

?Pulsar 通過 Bundle 漂移，高效均衡計算層負載

（圖片來源 Pulsar 社區(qū)）

解決集群擴縮容復雜度高和對集群影響大的問題，以及確保高峰期和故障時能夠進行擴容。

DKafka 的擴縮容流程較為復雜，需要進行分區(qū)遷移工作。在重大節(jié)假日活動期間，還需要根據(jù)預估的容量提前進行擴容和分區(qū)遷移均衡工作，這個過程耗時較長，耗費人力較多；并且在完成遷移后，還需要進行大量的負載均衡以解決熱點瓶頸問題。在遇到突發(fā)事件導致流量突增時，DKafka 只能通知上游降級并對 topic 的生產者進行限流，等到突增流量或高峰期過后，再在低峰期進行分區(qū)遷移或擴容。此外，之前提到的緩存/IO未隔離問題中的 pagecache 污染問題也表明，擴縮容對集群的影響較大。

縮容操作需要對下線 Broker 上的所有分區(qū)進行遷移

相比之下，Pulsar 的無痛擴容功能通過卸載集群中相對熱點的 Broker 上的 bundle，并讓其自動重分配到集群中的其他 Broker 上，從而實現(xiàn)計算層的負載均衡；對于存儲層的 Bookie 擴容，只需啟動服務，待集群運行一段時間后，計算層的 topic 分區(qū)的 segment 輪轉切 ensemble，將存儲層低負載節(jié)點逐漸利用起來，實現(xiàn)新老節(jié)點負載的雙向奔赴?；?Pulsar 的這些特點，它徹底解決了 DKafka 集群在高峰期/故障期間無法進行擴容的問題，這對于集群大面積故障后的快速恢復是一個重大提升。對于縮容場景，只需要在保證集群容量充足的情況下，將 Broker 節(jié)點逐臺停止，并將預下線的 Bookie 節(jié)點設置為 Readonly 狀態(tài)。待 Bookie 上的 Ledger 都過期后，即可下線這些 Bookie 節(jié)點。在提前 Readonly 并完成 Ledger 過期的情況下，每個 Bookie 節(jié)點的縮容過程可以在1分鐘內完成。

Pulsar 計算層 Broker 將 Bundle 漂移到新擴容到 Broker 上，讓擴容的機器立刻能夠提供計算能力

（圖片來源 Pulsar 社區(qū)）

Pulsar 存儲層 Bookie 擴容后不需要做任何操作，當計算層分片寫滿后輪轉，寫入新的分片時，將會選一批負載低的 Bookie 集合來存儲新的分段消息

（圖片來源 Pulsar 社區(qū)）

Pulsar 存儲層 Bookie 擴容后，隨著時間推移，新老節(jié)點間的負載均衡變化

故障模擬，具體分析 Pulsar 帶來的收益

根據(jù)上述分析，讓我們進行一次故障模擬，以了解Pulsar 如何解決 DKafka 的痛點以及在 Pulsar 出現(xiàn)故障時的處理方式：目前，線上 DKafka 的大部分集群使用的是 SSD 數(shù)據(jù)盤機型，為控制成本，日常存在機器級磁盤存儲熱點問題。當 odin 監(jiān)控出現(xiàn)故障時，由于無法感知故障發(fā)生，自愈系統(tǒng)無法進行存儲周期縮短工作，可能導致集群的多臺 Broker 數(shù)據(jù)盤存儲打滿，進而引發(fā)多臺 Broker 掛掉的故障。由于未能及時感知故障的發(fā)生，故障時間可能會持續(xù)數(shù)十分鐘。即使在此情況下拉起故障的 Broker，還可能面臨以下問題：

Q1：剩余的這些 Broker 將有更多分區(qū)以 leader 角色對客戶端提供生產/消費以及故障節(jié)點啟動后的副本數(shù)據(jù)同步，加重機器熱點情況。而解決機器熱點的切分區(qū) leader 操作流程復雜，粒度過小且沒有自動化。

A1：Pulsar 通過快速擴容或計算層的 bundle unload / split_unload 解決熱點，粒度大且負載均衡的自動化程度高。

Q2：一大波生產流量積壓，將對剩余 Broker cpu/網絡帶寬/磁盤 io 造成沖擊，出現(xiàn)集群容量嚴重不足的情況，并且 DKafka 無法在集群存在瓶頸時進行分區(qū)遷移，意味著無法進行集群擴容變更。

A2：Pulsar 節(jié)點對等特點，無狀態(tài)特點，計算層可以快速完成負載均衡，存儲層通常不存在熱點，即使有熱點也可以通過臨時 readonly 節(jié)點或者快速擴容解決。

Q3：掛掉的 Broker 上的分區(qū) follower 需要從分區(qū) leader 同步數(shù)據(jù)，將對分區(qū) leader Broker 的 pagecache 進行污染，除了同步數(shù)據(jù)的讀盤操作，還將因 pagecache 污染，造成更多的消費消息讀盤操作，用戶感知現(xiàn)象為生產/消費耗時增漲。由于上述提及的網卡流出瓶頸，部分分區(qū)可能永遠無法完成同步（內部優(yōu)化策略，優(yōu)先保生產，在大面積故障場景下是負優(yōu)化），這又加劇了 pagecache 污染持續(xù)時間。

A3: Pulsar 存算組件節(jié)點對等無需同步數(shù)據(jù)，計算層條帶化寫入存儲層，并且有多級緩存；另參照上述【緩存 / IO 未隔離問題】

DKafka 主從架構，分區(qū) follower 需要從分區(qū) leader 同步數(shù)據(jù)；Pulsar 存算分離架構，由 Broker 進行條帶化寫入 Bookie

（圖片來源 Pulsar 社區(qū)）

Q4：由于 DKafka 存算一體的架構，無法通過擴容快速進行負載均衡，只能進行生產限流。用戶感知現(xiàn)象為數(shù)據(jù)不及時。在數(shù)據(jù)通道場景中，極端情況下，限流可能導致數(shù)據(jù)不完整，如日志在宿主機上保留時間短或程序未 catch 這類異常情況而直接丟棄，用戶感知現(xiàn)象為丟失一段時間數(shù)據(jù)，如看板指標某段時間跌 0，查不到某段時間訂單，查不到某段時間日志等。

A4：Pulsar 通過快速擴容解決，計算層負載均衡手段通過 unload bundle，存儲層 Bookie 擴容后不需進行任何操作。

Q5：集群中部分分區(qū) ar 都分配在磁盤打滿的故障節(jié)點上，部分分區(qū)無法提供消息生產能力，導致磁盤上數(shù)據(jù)過期丟失

A5：Pulsar 計算層無狀態(tài)的設計，計算層自動進行 bundle 故障轉移，讓剩余 Broker 繼續(xù)為故障 Broker 上的分區(qū)提供服務；計算層還能夠通過對 topic 分區(qū) segment 切 ensemble 列表進行存儲層故障轉移，可以做到服務生產不中斷；需要注意的是存儲層故障節(jié)點容忍數(shù)為 ensemble ack quorum -1，副本數(shù)為 0 的 segment 可能導致 Broker 無法加載部分分區(qū)。最后存儲層 Bookie 還支持配置存儲高水位拒絕寫入和 readonly 方式啟動，即便是存儲容量不足的情況下，也是可以通過快速擴容寫入新數(shù)據(jù) + ?readonly 讀取老數(shù)據(jù)的方式，平穩(wěn)渡過這次故障。

Pulsar 計算層故障，節(jié)點對等特性支持無痛轉移故障節(jié)點上的計算負載，集群能夠持續(xù)提供消息生產能力

（圖片來源 Pulsar 社區(qū)）

Pulsar 存儲層，節(jié)點對等特性，從架構層面優(yōu)化，做到更高的可用性

（圖片來源 Pulsar 社區(qū)）

總結

從上述問題和故障案例中，我們可以看出 Pulsar 在存算分離架構方面的改進，結合緩存/IO隔離、節(jié)點對等、計算節(jié)點的無狀態(tài)設計、Bundle 機制以及 Ensemble 機制，有效地解決了 DKafka 集群在日常運維過程中遇到的問題，顯著提升了消息系統(tǒng)集群運維管理員的運維體驗。然而，Pulsar 在架構上的復雜性以及引擎監(jiān)控指標的數(shù)量級關系上，與 DKafka 相比也有顯著的增長。這對引擎研發(fā)和運維人員來說，無疑是一個更大的挑戰(zhàn)。

---

---

數(shù)據(jù)夜談

聊聊看，你們在大數(shù)據(jù)消息系統(tǒng)運維有遇到哪些問題，是如何解決的？如需與我們進一步交流探討，也可直接私信后臺。

作者將選取1則最有意義的留言，送出暖暖保溫杯一個。1月16日晚9點開獎。

文章來源地址http://www.zghlxwxcb.cn/news/detail-796992.html