您好,登錄后才能下訂單哦!
作者:個推平臺研發(fā)工程師 祥子
在個推的推送場景中,消息隊列在整個系統(tǒng)中占有非常重要的位置。
當 APP 有推送需求的時候, 會向個推發(fā)送一條推送命令,接到推送需求后,我們會把APP要求推送消息的用戶放入下發(fā)隊列中,進行消息下發(fā);當同時有多個APP進行消息下發(fā)時,難免會出現(xiàn)資源競爭的情況, 因此就產(chǎn)生了優(yōu)先級隊列的需求,在下發(fā)資源固定的情況下, 高優(yōu)先級的用戶需要有更多的下發(fā)資源。
針對以上場景,個推基于 Kafka 設(shè)計了第一版的優(yōu)先級隊列方案。Kafka 是 LinkedIn 開發(fā)的一個高性能、分布式消息系統(tǒng);Kafka 在個推有非常廣泛的應(yīng)用,如日志收集、在線和離線消息分發(fā)等。
架構(gòu)
在該方案中,個推將優(yōu)先級統(tǒng)一設(shè)定為高、中、低三個級別。具體操作方案如下:
對某個優(yōu)先級根據(jù) task (單次推送任務(wù))維度,存入不同的 Topic,一個 task 只寫入一個 Topic,一個 Topic 可存多個 task;
Kafka 方案遇到的問題
隨著個推業(yè)務(wù)的不斷發(fā)展,接入的 APP 數(shù)量逐漸增多,第一版的優(yōu)先級方案也逐漸暴露出一些問題:
基于上述問題,個推進行了新一輪的技術(shù)選型, 我們需要可以創(chuàng)建大量的 Topic, 同時吞吐性能不能比 Kafka 遜色。經(jīng)過一段時間的調(diào)研,Apache Pulsar 引起了我們的關(guān)注。
Apache Pulsar 是一個企業(yè)級的分布式消息系統(tǒng),最初由 Yahoo 開發(fā),在 2016 年開源,并于2018年9月畢業(yè)成為 Apache 基金會的頂級項目。Pulsar 已經(jīng)在 Yahoo 的生產(chǎn)環(huán)境使用了三年多,主要服務(wù)于Mail、Finance、Sports、 Flickr、 the Gemini Ads platform、 Sherpa (Yahoo 的 KV 存儲)。
架構(gòu)
Topic 數(shù)量
Pulsar 可以支持百萬級別 Topic 數(shù)量的擴展,同時還能一直保持良好的性能。Topic 的伸縮性取決于它的內(nèi)部組織和存儲方式。Pulsar 的數(shù)據(jù)保存在 bookie (BookKeeper 服務(wù)器)上,處于寫狀態(tài)的不同 Topic 的消息,在內(nèi)存中排序,最終聚合保存到大文件中,在 Bookie 中需要更少的文件句柄。另一方面 Bookie 的 IO 更少依賴于文件系統(tǒng)的 Pagecache,Pulsar 也因此能夠支持大量的主題。
消費模型
Pulsar 支持三種消費模型:Exclusive、Shared 和Failover。
Exclusive (獨享):一個 Topic 只能被一個消費者消費。Pulsar 默認使用這種模式。
Shared(共享):共享模式,多個消費者可以連接到同一個 Topic,消息依次分發(fā)給消費者。當一個消費者宕機或者主動斷開連接時,那么分發(fā)給這個消費者的未確認(ack)的消息會得到重新調(diào)度,分發(fā)給其他消費者。
Failover (災(zāi)備):一個訂閱同時只有一個消費者,可以有多個備份消費者。一旦主消費者故障,則備份消費者接管。不會出現(xiàn)同時有兩個活躍的消費者。
Exclusive和Failover訂閱,僅允許一個消費者來使用和消費每個訂閱的Topic。這兩種模式都按 Topic 分區(qū)順序使用消息。它們最適用于需要嚴格消息順序的流(Stream)用例。
Shared 允許每個主題分區(qū)有多個消費者。同一個訂閱中的每個消費者僅接收Topic分區(qū)的一部分消息。Shared最適用于不需要保證消息順序隊列(Queue)的使用模式,并且可以按照需要任意擴展消費者的數(shù)量。
存儲
Pulsar 引入了 Apache BookKeeper 作為存儲層,BookKeeper 是一個專門為實時系統(tǒng)優(yōu)化過的分布式存儲系統(tǒng),具有可擴展、高可用、低延遲等特性。具體介紹,請參考 BookKeeper官網(wǎng)。
Segment
BookKeeper以 Segment (在 BookKeeper 內(nèi)部被稱作 ledger) 作為存儲的基本單元。從 Segment 到消息粒度,都會均勻分散到 BookKeeper 的集群中。這種機制保證了數(shù)據(jù)和服務(wù)均勻分散在 BookKeeper 集群中。
Pulsar 和 Kafka 都是基于 partition 的邏輯概念來做 Topic 存儲的。最根本的不同是,Kafka 的物理存儲是以 partition 為單位的,每個 partition 必須作為一個整體(一個目錄)存儲在某個 broker 上。 而 Pulsar 的 partition 是以 segment 作為物理存儲的單位,每個 partition 會再被打散并均勻分散到多個 bookie 節(jié)點中。
這樣的直接影響是,Kafka 的 partition 的大小,受制于單臺 broker 的存儲;而 Pulsar 的 partition 則可以利用整個集群的存儲容量。
擴容
當 partition 的容量達到上限后,需要擴容的時候,如果現(xiàn)有的單臺機器不能滿足,Kafka 可能需要添加新的存儲節(jié)點,并將 partition 的數(shù)據(jù)在節(jié)點之間搬移達到 rebalance 的狀態(tài)。
而 Pulsar 只需添加新的 Bookie 存儲節(jié)點即可。新加入的節(jié)點由于剩余空間大,會被優(yōu)先使用,接收更多的新數(shù)據(jù);整個擴容過程不涉及任何已有數(shù)據(jù)的拷貝和搬移。
Broker 故障
Pulsar 在單個節(jié)點失敗時也會體現(xiàn)同樣的優(yōu)勢。如果 Pulsar 的某個服務(wù)節(jié)點 broker 失效,由于 broker 是無狀態(tài)的,其他的 broker 可以很快接管 Topic,不會涉及 Topic 數(shù)據(jù)的拷貝;如果存儲節(jié)點 Bookie 失效,在集群后臺中,其他的 Bookie 會從多個 Bookie 節(jié)點中并發(fā)讀取數(shù)據(jù),并對失效節(jié)點的數(shù)據(jù)自動進行恢復(fù),對前端服務(wù)不會造成影響。
Bookie 故障
Apache BookKeeper 中的副本修復(fù)是 Segment (甚至是 Entry)級別的多對多快速修復(fù)。這種方式只會復(fù)制必須的數(shù)據(jù),這比重新復(fù)制整個主題分區(qū)要精細。如下圖所示,當錯誤發(fā)生時, Apache BookKeeper 可以從 bookie 3 和 bookie 4 中讀取 Segment 4 中的消息,并在 bookie 1 處修復(fù) Segment 4。所有的副本修復(fù)都在后臺進行,對 Broker 和應(yīng)用透明。
當某個 Bookie 節(jié)點出錯時,BookKeeper會自動添加可用的新 Bookie 來替換失敗的 Bookie,出錯的 Bookie 中的數(shù)據(jù)在后臺恢復(fù),所有 Broker 的寫入不會被打斷,而且不會犧牲主題分區(qū)的可用性。
在設(shè)計思路上,Pulsar 方案和 Kafka 方案并沒有多大區(qū)別。但在新方案中,個推技術(shù)團隊借助 Pulsar 的特性,解決了 Kafka 方案中存在的問題。
dbStorage_rocksDB_blockCacheSize
設(shè)置的足夠大;當消息體量大,出現(xiàn)backlog 大量堆積時, 使用默認大小(256M)會出現(xiàn)讀耗時過大情況,導(dǎo)致消費變慢。backlogQuotaDefaultLimitGB
設(shè)置的足夠大(默認10G), 避免因為默認使用producer_request_hold
模式出現(xiàn) block producer 的情況;當然可以根據(jù)實際業(yè)務(wù)選擇合適的 backlogQuotaDefaultRetentionPolicy
。現(xiàn)在, 個推針對優(yōu)先級中間件的改造方案已經(jīng)在部分現(xiàn)網(wǎng)業(yè)務(wù)中試運行,對于 Pulsar 的穩(wěn)定性,我們還在持續(xù)關(guān)注中。
作為一個2016 年才開源的項目,Pulsar 擁有非常多吸引人的特性,也彌補了其他競品的短板,例如跨地域復(fù)制、多租戶、擴展性、讀寫隔離等。盡管在業(yè)內(nèi)使用尚不廣泛, 但從現(xiàn)有的特性來說, Pulsar 表現(xiàn)出了取代 Kafka 的趨勢。在使用 Pulsar 過程中,我們也遇到了一些問題, 在此特別感謝翟佳和郭斯杰(兩位均為 Stream Native 的核心工程師、開源項目 Apache Pulsar 的 PMC 成員)給我們提供的支持和幫助。
參考文獻:
[1] 比拼 Kafka, 大數(shù)據(jù)分析新秀Pulsar 到底好在哪(https://www.infoq.cn/article/1UaxFKWUhUKTY1t_5gPq)
[2] 開源實時數(shù)據(jù)處理系統(tǒng)Pulsar:一套搞定Kafka+Flink+DB(https://juejin.im/post/5af414365188256717765441)
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。