建站
咨詢
售后
建站咨詢
新聞中心
今天就跟大家聊聊有關(guān)怎樣實(shí)現(xiàn)Apache Pulsar 與 Kafka 在金融場(chǎng)景下的性能分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。
為游仙等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及游仙網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、游仙網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！
背景
Apache Pulsar 是下一代分布式消息流平臺(tái)，采用計(jì)算存儲(chǔ)分層架構(gòu)，具備多租戶、高一致、高性能、百萬 topic、數(shù)據(jù)平滑遷移等諸多優(yōu)勢(shì)。越來越多的企業(yè)正在使用 Pulsar 或者嘗試將 Pulsar 應(yīng)用到生產(chǎn)環(huán)境中。
騰訊把 Pulsar 作為計(jì)費(fèi)系統(tǒng)的消息總線來支撐千億級(jí)在線交易。騰訊計(jì)費(fèi)體量龐大，要解決的核心問題就是必須確保錢貨一致。首先，保證每一筆支付交易不出現(xiàn)錯(cuò)賬，做到高一致、高可靠。其次，保證計(jì)費(fèi)承載的所有業(yè)務(wù) 7*24 可用，做到高可用、高性能。計(jì)費(fèi)消息總線必須具備這些能力。
Pulsar 架構(gòu)解析
在一致性方面，Pulsar 采用 Quorum 算法，通過 write quorum 和 ack quorum 來保證分布式消息隊(duì)列的副本數(shù)和強(qiáng)一致寫入的應(yīng)答數(shù)(A>W/2)。在性能方面，Pulsar 采用 Pipeline 方式生產(chǎn)消息，通過順序?qū)懞蜅l帶化寫入降低磁盤 IO 壓力，多種緩存減少網(wǎng)絡(luò)請(qǐng)求加快消費(fèi)效率。
Pulsar 性能高主要體現(xiàn)在網(wǎng)絡(luò)模型、通信協(xié)議、隊(duì)列模型、磁盤 IO 和條帶化寫入。下面我會(huì)一一詳細(xì)講解。
網(wǎng)絡(luò)模型
Pulsar Broker 是一個(gè)典型的 Reactor 模型，主要包含一個(gè)網(wǎng)絡(luò)線程池，負(fù)責(zé)處理網(wǎng)絡(luò)請(qǐng)求，進(jìn)行網(wǎng)絡(luò)的收發(fā)以及編解碼，接著把請(qǐng)求通過請(qǐng)求隊(duì)列推送給核心線程池進(jìn)行處理。首先，Pulsar 采用多線程方式，充分利用現(xiàn)代系統(tǒng)的多核優(yōu)勢(shì)，把同一任務(wù)請(qǐng)求分配給同一個(gè)線程處理，盡量避免線程之間切換帶來的開銷。其次，Pulsar 采用隊(duì)列方式實(shí)現(xiàn)了網(wǎng)絡(luò)處理模塊及核心處理模塊的異步解耦，實(shí)現(xiàn)了網(wǎng)絡(luò)處理和文件 I/O 并行處理，極大地提高了整個(gè)系統(tǒng)的效率。
通信協(xié)議
信息（message）采用二進(jìn)制編碼，格式簡(jiǎn)單；客戶端生成二進(jìn)制數(shù)據(jù)直接發(fā)送給 Pulsar 后端 broker，broker 端不解碼直接發(fā)送給 bookie 存儲(chǔ)，存儲(chǔ)格式也是二進(jìn)制，所以消息生產(chǎn)消費(fèi)過程沒有任何編解碼操作。消息的壓縮以及批量發(fā)送都是在客戶端完成，這能進(jìn)一步提升 broker 處理消息的能力。
隊(duì)列模型
Pulsar 對(duì)主題（topic）進(jìn)行分區(qū)（partition），并盡量將不同的分區(qū)分配到不同的 Broker，實(shí)現(xiàn)水平擴(kuò)展。Pulsar 支持在線調(diào)整分區(qū)數(shù)量，理論上支持無限吞吐量。雖然 ZooKeeper 的容量和性能會(huì)影響 broker 個(gè)數(shù)和分區(qū)數(shù)量，但該限制上限非常大，可以認(rèn)為沒有上限。
磁盤 IO
消息隊(duì)列屬于磁盤 IO 密集型系統(tǒng)，所以優(yōu)化磁盤 IO 至關(guān)重要。Pulsar 中的磁盤相關(guān)操作主要分為操作日志和數(shù)據(jù)日志兩類。操作日志用于數(shù)據(jù)恢復(fù)，采用完全順序?qū)懙哪Ｊ剑瑢懭氤晒纯烧J(rèn)為生產(chǎn)成功，因此 Pulsar 可以支持百萬主題，不會(huì)因?yàn)殡S機(jī)寫而導(dǎo)致性能急劇下降。
操作日志也可以是亂序的，這樣可以讓操作日志寫入保持最佳寫入速率，數(shù)據(jù)日志會(huì)進(jìn)行排序和去重，雖然出現(xiàn)寫放大的情況，但是這種收益是值得的：通過將操作日志和數(shù)據(jù)日志掛在到不同的磁盤上，將讀寫 IO 分離，進(jìn)一步提升整個(gè)系統(tǒng) IO 相關(guān)的處理能力。
條帶化寫入
條帶化寫入能夠利用更多的 bookie 節(jié)點(diǎn)來進(jìn)行 IO 分擔(dān)；Bookie 設(shè)置了寫緩存和讀緩存。最新的消息放在寫緩存，其他消息會(huì)批量從文件讀取加入到讀緩存中，提升讀取效率。
從架構(gòu)來看，Pulsar 在處理消息的各個(gè)流程中沒有明顯的卡點(diǎn)。操作日志持久化只有一個(gè)線程來負(fù)責(zé)刷盤，可能會(huì)造成卡頓。根據(jù)磁盤特性，可以設(shè)置多塊盤，多個(gè)目錄，提升磁盤讀寫性能，這完全能夠滿足我們的需求。
測(cè)試
在騰訊計(jì)費(fèi)場(chǎng)景中，我們?cè)O(shè)置相同的場(chǎng)景，分別對(duì) Pulsar 和 Kafka 進(jìn)行了壓測(cè)對(duì)比，具體的測(cè)試場(chǎng)景如下。
壓測(cè)數(shù)據(jù)如下:
以上數(shù)據(jù)可以看到，網(wǎng)絡(luò) IO 方面，3 個(gè)副本多分區(qū)的情況下，Pulsar 幾乎要把 broker 網(wǎng)卡出流量跑滿，因?yàn)橐环輸?shù)據(jù)需要在 broker 端分發(fā) 3 次，這是計(jì)算存儲(chǔ)分離的代價(jià)。
Kafka 的性能數(shù)據(jù)有點(diǎn)讓人失望，整體性能沒有上去，這應(yīng)該和 Kafka 本身的副本同步機(jī)制有關(guān)：Kafka 采用的是 follow 同步拉取的策略，導(dǎo)致整體效率并不高。
延遲方面，Pulsar 在生產(chǎn)端表現(xiàn)更優(yōu)越些，當(dāng)資源沒有到達(dá)瓶頸時(shí)，整個(gè)時(shí)耗 99% 在 10 毫秒以內(nèi)，在垃圾回收（Garbage Collection，GC）和創(chuàng)建操作日志文件時(shí)會(huì)出現(xiàn)波動(dòng)。
從壓測(cè)的結(jié)果來看，在高一致的場(chǎng)景下，Pulsar 性能優(yōu)于 Kafka。如果設(shè)置 log.flush.interval.messages=1 的情況，Kafka 性能表現(xiàn)更差，kafka 在設(shè)計(jì)之初就是為高吞吐，并沒有類似直接同步刷盤這些參數(shù)。
此外，我們還測(cè)試了其他場(chǎng)景，比如百萬 Topic 和跨地域復(fù)制等。在百萬 Topic 場(chǎng)景的生產(chǎn)和消費(fèi)場(chǎng)景測(cè)試中，Pulsar 沒有因?yàn)?Topic 數(shù)量增長(zhǎng)而出現(xiàn)性能急劇下降的情況，而 Kafka 因?yàn)榇罅康碾S機(jī)寫導(dǎo)致系統(tǒng)快速變慢。
Pulsar 原生支持跨地域復(fù)制，并支持同步和異步兩種方式。Kafka 在同城跨地域復(fù)制中，吞吐量不高，復(fù)制速度很慢，所以在跨地域復(fù)制場(chǎng)景中，我們測(cè)試了 Pulsar 同步復(fù)制方式，存儲(chǔ)集群采用跨城部署，等待 ACK 時(shí)必須包含多地應(yīng)答，測(cè)試使用的相關(guān)參數(shù)和同城一致。測(cè)試結(jié)果證明，在跨城情況下，Pulsar 吞吐量可以達(dá)到 28萬QPS。當(dāng)然，跨城跨地域復(fù)制的性能很大程度依賴于當(dāng)前的網(wǎng)絡(luò)質(zhì)量。
可用性分析
作為新型分布式消息流平臺(tái)，Pulsar 有很多優(yōu)勢(shì)。得益于 bookie 的分片處理以及 ledger 選擇存儲(chǔ)節(jié)點(diǎn)的策略，運(yùn)維 Pulsar 非常簡(jiǎn)單，可以擺脫類似 Kafka 手動(dòng)平衡數(shù)據(jù)煩擾。但 Pulsar 也不是十全十美，本身也存在一些問題，社區(qū)仍在改進(jìn)中。
Pulsar 對(duì) ZooKeeper 的強(qiáng)依賴
Pulsar 對(duì) ZooKeeper 有很強(qiáng)的依賴。在極限情況下，ZooKeeper 集群出現(xiàn)宕機(jī)或者阻塞，會(huì)導(dǎo)致整個(gè)服務(wù)宕機(jī)。ZooKeeper 集群奔潰的概率相對(duì)小，畢竟 ZooKeeper 經(jīng)過了大量線上系統(tǒng)的考驗(yàn)，使用還是相對(duì)廣泛的。但 ZooKeeper 堵塞的概率相對(duì)較高，比如在百萬 Topic 場(chǎng)景下，會(huì)產(chǎn)生百萬級(jí)的 ledger 元數(shù)據(jù)信息，這些數(shù)據(jù)都需要與 ZooKeeper 進(jìn)行交互。
例如，創(chuàng)建一次主題（topic），需要?jiǎng)?chuàng)建主題分區(qū)元數(shù)據(jù)、Topic 名、Topic 存儲(chǔ) ledger 節(jié)點(diǎn)；而創(chuàng)建一次 ledger 又需要?jiǎng)?chuàng)建和刪除唯一的 ledgerid 和 ledger 元數(shù)據(jù)信息節(jié)點(diǎn)，一共需要 5 次 ZooKeeper 寫入操作，一次訂閱也需要類似的 4 次 ZooKeeper 寫入操作，所以總共需要 9 次寫入操作。如果同時(shí)集中創(chuàng)建百萬級(jí)的主題，勢(shì)必會(huì)對(duì) ZooKeeper 造成很大的壓力。
Pulsar 具有分散 ZooKeeper 部署的能力，能夠在一定程度上緩解 ZooKeeper 的壓力，依賴最大的是 zookeeperServer 這個(gè) ZooKeeper 集群。從之前的分析來看，寫操作相對(duì)可控，可以通過控制臺(tái)創(chuàng)建 Topic。bookie 依賴的 ZooKeeper 操作頻率最高，如果該 ZooKeeper 出現(xiàn)阻塞，當(dāng)前寫入并不會(huì)造成影響。
可以按照同樣的思路優(yōu)化對(duì) zookeeperServerzk 的依賴。至少對(duì)于當(dāng)前的服務(wù)可以持續(xù)一段時(shí)間，給 ZooKeeper 足夠的時(shí)間進(jìn)行恢復(fù)；其次減少 ZooKeeper 的寫入次數(shù)，只用于必要的操作，比如 broker 選舉等。像 broker 的負(fù)載信息，可以尋求其他存儲(chǔ)介質(zhì)，尤其是當(dāng)一個(gè) broker 服務(wù)大量主題時(shí)，這個(gè)信息會(huì)達(dá)到兆（M）級(jí)別。我們正在和 Pulsar 社區(qū)攜手優(yōu)化 broker 負(fù)載功能。
Pulsar 內(nèi)存管理稍復(fù)雜
Pulsar 的內(nèi)存由 JVM 的堆內(nèi)存和堆外存構(gòu)成，消息的發(fā)送和緩存通過堆外內(nèi)存來存儲(chǔ)，減少 IO 造成的垃圾回收（GC）；堆內(nèi)存主要緩存 ZooKeeper 相關(guān)數(shù)據(jù)，比如 ledger 的元數(shù)據(jù)信息和訂閱者重推的消息 ID 緩存信息，通過 dump 內(nèi)存分析發(fā)現(xiàn)，一個(gè) ledger 元數(shù)據(jù)信息需要占用約 10K，一個(gè)訂閱者者重推消息 ID 緩存初始為 16K，且會(huì)持續(xù)增長(zhǎng)。當(dāng) broker 的內(nèi)存持續(xù)增長(zhǎng)時(shí)，最終頻繁進(jìn)行整體垃圾回收（full GC），直到最終退出。
要解決這個(gè)問題，首先要找到可以減少內(nèi)存占用的字段，比如 ledger 元數(shù)據(jù)信息里面的 bookie 地址信息。每個(gè) ledger 都會(huì)創(chuàng)建對(duì)象，而 bookie 節(jié)點(diǎn)非常有限，可以通過全局變量來減少創(chuàng)建不必要的對(duì)象；訂閱者重推消息 ID 緩存可以把初始化控制在 1K 內(nèi)，定期進(jìn)行縮容等。這些操作可以大大提升 Broker 的可用性。
和 Kafka 相比，Pulsar broker 的優(yōu)點(diǎn)比較多，Pulsar 能夠自動(dòng)進(jìn)行負(fù)載均衡，不會(huì)因?yàn)槟硞€(gè) broker 負(fù)載過高導(dǎo)致服務(wù)不穩(wěn)定，可以快速擴(kuò)容，降低整個(gè)集群的負(fù)載。
看完上述內(nèi)容，你們對(duì)怎樣實(shí)現(xiàn)Apache Pulsar 與 Kafka 在金融場(chǎng)景下的性能分析有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。
網(wǎng)頁名稱：怎樣實(shí)現(xiàn)ApachePulsar與Kafka在金融場(chǎng)景下的性能分析
轉(zhuǎn)載來源：http://www.ef60e0e.cn/article/jsgocd.html
