[[385156]]

本文作者為 Jesse Anderson。內(nèi)容由 StreamNative 翻譯并整理。 本文以三個(gè)實(shí)際使用場景為例，從 CTO 的視角出發(fā)，在技術(shù)等方面對比 Kafka 和 Pulsar。閱讀本文需要大約 8 分鐘。

在評估新技術(shù)時(shí)，高層管理人員的視角通常與中層管理人員、架構(gòu)師、數(shù)據(jù)工程師等有所不同。高層管理人員不僅要關(guān)注基準(zhǔn)測試結(jié)果、產(chǎn)品支持的特性，還要從長遠(yuǎn)角度考慮新技術(shù)的可靠性，新技術(shù)能夠?yàn)槠髽I(yè)帶來哪些競爭優(yōu)勢，以及是否可以縮短上市時(shí)間、節(jié)約開銷。

我是 Big Data Institute 的常務(wù)董事，技術(shù)評估是我的一項(xiàng)主要工作。我們幫助企業(yè)根據(jù)業(yè)務(wù)需求選擇并落地最合適的技術(shù)。我們不與供應(yīng)商合作，因此客戶尤為看中我們能夠客觀地評估不同的技術(shù)。

在本文中，我將從 CTO 的視角出發(fā)，對比 Apache Pulsar 和 Apache Kafka。只進(jìn)行理論上的對比空洞無效，也不能幫助我們作出決策，實(shí)際用例才真正值得參考。所以，在本文中，我會通過一些常見的實(shí)際使用場景來對比 Pulsar 和 Kafka，即 簡單消息使用場景、復(fù)雜消息使用場景和高級消息使用場景 。在這些實(shí)際使用場景下，Pulsar 和 Kafka 的表現(xiàn)能夠幫助我們更好地理解二者的性能和優(yōu)勢，進(jìn)而作出決策。

簡單消息使用場景

假設(shè)有一個(gè)企業(yè)，之前從未使用過消息系統(tǒng)，現(xiàn)在需要通過一個(gè)簡單的消息系統(tǒng)，將消息從位置 A 發(fā)送到位置 B，但不需要復(fù)制消息。

數(shù)據(jù)架構(gòu)師團(tuán)隊(duì)在深入研究 Pulsar 和 Kafka 的業(yè)務(wù)案例后，得出如下結(jié)論：在這一使用場景中，Pulsar 和 Kafka 都沒有絕對優(yōu)勢。并且，他們認(rèn)為在短時(shí)間內(nèi)，該使用場景基本不會發(fā)生改變。

對于類似這樣的簡單消息使用場景而言，我也贊同 Pulsar 和 Kafka 都沒有絕對優(yōu)勢。僅從技術(shù)角度出發(fā)，Pulsar 和 Kafka 這一回合打成平局，那么我們只能考慮成本。二者的運(yùn)營成本、員工培訓(xùn)成本分別是多少？我打算根據(jù) Kafka 或 Pulsar 的服務(wù)提供商的收費(fèi)標(biāo)準(zhǔn)進(jìn)行對比。 對比開銷時(shí)，選好服務(wù)提供商也可以在一定程度上減少運(yùn)營成本和員工培訓(xùn)成本 。Kafka 的云服務(wù)提供商，我參考了使用  Kafka API（Azure）  ^[1] 的  Confluent Cloud ^[2] 、 MSK（AWS） ^[3] 和  Event Hubs ^[4] 。Pulsar 的云服務(wù)提供商，我選擇  StreamNative Cloud ^[5] 。

對比結(jié)果

出于穩(wěn)妥考慮，我們決定選擇 Kafka API。目前，已有多種技術(shù)支持非 Kafka broker 使用 Kafka API 或傳輸協(xié)議。使用 Kafka API，非 Kafka broker 可通過添加新庫支持 Kafka 的傳輸協(xié)議，保證對 Kafka API 的兼容性，從而最大化技術(shù)選擇的多樣性。例如，可以通過修改 Kafka API 的實(shí)現(xiàn)重新編譯或通過 Pulsar broker 解析 Kafka 的協(xié)議（KOP），將 Pulsar 用作 Kafka 的后端。

我們在對比單位成本后，選擇了 成本效益高 的一方。Kafka API 可以保證后端質(zhì)量，用戶在后端之間的數(shù)據(jù)移動不會受到影響，有效規(guī)避風(fēng)險(xiǎn)。即使社區(qū)不活躍，技術(shù)熱度不高，我們的使用也不會受到影響。

復(fù)雜消息使用場景

假設(shè)一個(gè)公司需要 復(fù)雜消息系統(tǒng) 。由于需要處理世界各地的數(shù)據(jù)，必須支持跨地域復(fù)制。該企業(yè)一直在使用消息系統(tǒng)，因此對實(shí)時(shí)系統(tǒng)的復(fù)雜性有一定的了解，也發(fā)現(xiàn)了當(dāng)前消息系統(tǒng)的不足之處。因此該企業(yè)對消息系統(tǒng)的要求是能夠處理高級的消息傳遞和復(fù)雜的消息特性。

數(shù)據(jù)架構(gòu)師團(tuán)隊(duì)和股東以及業(yè)務(wù)部門詳細(xì)討論了當(dāng)前和未來需求。最后得出的結(jié)論是，Pulsar 和 Kafka 各有優(yōu)勢。同時(shí)，他們認(rèn)為隨著時(shí)間的推移，該使用場景和數(shù)據(jù)量都會有所增長。

在這種情況下，Pulsar 和 Kafka 難分勝負(fù)。要想作出正確決策，必須深入研究二者的使用場景。

跨地域復(fù)制

Kafka 既提供私有的（價(jià)格高）跨地域復(fù)制，也提供開源的（附加服務(wù)）跨地域復(fù)制解決方案。私有的跨地域復(fù)制解決方案為其內(nèi)置特性，但價(jià)格高昂。開源的解決方案（MirrorMaker）實(shí)際上就是數(shù)據(jù)復(fù)制，但由于不是其內(nèi)置特性，會增加運(yùn)營開銷。

Pulsar 提供開源內(nèi)置的跨地域復(fù)制特性，支持復(fù)雜的復(fù)制策略。對于使用場景和數(shù)據(jù)量都在增加的企業(yè)而言，顯然，支持內(nèi)置跨地域復(fù)制策略的 Pulsar 完勝。

就跨地域復(fù)制而言，我們選擇 Pulsar。

復(fù)雜消息

由于企業(yè)正在向新消息平臺遷移，消息系統(tǒng)最好可以處理新使用場景。數(shù)據(jù)架構(gòu)師團(tuán)隊(duì)一直在了解各個(gè)平臺，嘗試尋找最佳解決方案。在當(dāng)前使用的消息系統(tǒng)中，一旦出現(xiàn)處理錯(cuò)誤，必須重新生成消息，再手動重試，因此最好還可以引入消息延遲發(fā)送。另外，當(dāng)前消息系統(tǒng)的 schema 實(shí)施功能也有待加強(qiáng)，各個(gè)團(tuán)隊(duì)選擇不同的 schema 實(shí)現(xiàn)時(shí)，團(tuán)隊(duì)合作的難度顯著增加。

Kafka 沒有內(nèi)置死信隊(duì)列特性，一旦消息處理失敗，必須手動處理，或修改代碼重試。Kafka 也沒有延遲發(fā)送消息的內(nèi)置機(jī)制，延遲發(fā)送消息流程復(fù)雜、工作量大。另外，Kafka 沒有內(nèi)置 schema 實(shí)施機(jī)制，導(dǎo)致云服務(wù)提供商分別提供了不同的 schema 解決方案。

Pulsar 內(nèi)置死信隊(duì)列特性，當(dāng)消息處理失敗，收到否認(rèn) ack 時(shí)，Pulsar 可以自動重試，但次數(shù)有限。Pulsar 也支持延遲發(fā)送消息，可以設(shè)定延遲時(shí)間。對于 Pulsar 而言，schema 級別高，因此 Pulsar 有內(nèi)置 schema 注冊，Pulsar API 也原生支持 schema。

就復(fù)雜消息而言，我們選擇 Pulsar。

高級消息傳遞

隨著對架構(gòu)的深入了解，我們發(fā)現(xiàn)為了確保均勻分配資源，需要循環(huán)發(fā)送同一 topic 上的數(shù)據(jù)，并且需要通過排序確保消息有序排列。

Kafka 不能分發(fā)消息給指定的 consumer。當(dāng) consumer 接收到不屬于它消費(fèi)的消息時(shí)，要保證這些消息被正確消費(fèi)，我們只能重新發(fā)送這些消息到額外的 topic 中，但這樣會造成數(shù)據(jù)冗余，增加使用成本。因此，我們需要可以制定路由規(guī)則發(fā)送給指定 consumer 的產(chǎn)品。

Pulsar broker 可以通過制定的路由規(guī)則，把一個(gè) topic 的不同消息根據(jù)路由規(guī)則發(fā)送到指定的 consumer 中。Pulsar broker 輕松實(shí)現(xiàn)了我們的目標(biāo)，無需任何額外工作。

就高級消息傳遞而言，我們選擇 Pulsar。

部署和社區(qū)

為了全面比較 Pulsar 和 Kafka，我們還需要看一下二者的部署數(shù)量和社區(qū)概況。

從服務(wù)市場來看，Kafka 的提供商更多，銷售和支持 Kafka 產(chǎn)品的團(tuán)隊(duì)也更多。Kafka 和 Pulsar 的開源社區(qū)都積極活躍，但 Kafka 的社區(qū)規(guī)模更大。

從使用市場來看，Kafka 和 Pulsar 都已部署在大公司的大型生產(chǎn)環(huán)境中。在生產(chǎn)環(huán)境中部署 Kafka 的公司在數(shù)量上更勝一籌。

從用戶數(shù)量來看，Kafka 的用戶更多。但是，數(shù)據(jù)工程師團(tuán)隊(duì)認(rèn)為， Kafka 的使用者可以輕松學(xué)習(xí) Pulsar。

就服務(wù)支持和社區(qū)而言，我們選擇 Kafka。但值得一提的是，Pulsar 社區(qū)正在迅速發(fā)展。

對比結(jié)果

由于 Pulsar 和 Kafka 在這一使用場景中都有明顯的優(yōu)劣勢，決策難度大大增加。

Pulsar 可以在社區(qū)和部署上奮起直追，Kafka 則可以努力豐富產(chǎn)品特性。

在作出決策前，我們先來總結(jié)一下，該企業(yè)在技術(shù)上最看重哪方面；在技術(shù)方面，我們是否需要做最保守的選擇。根據(jù)以往的經(jīng)驗(yàn)，新的開源技術(shù)會帶來更多驚喜，因此我們更傾向于選擇 Pulsar。

如果選擇 Kafka，我們需要承擔(dān)向業(yè)務(wù)贊助商坦誠 “我們無法處理這一使用場景” 的風(fēng)險(xiǎn)。甚至，即使支付大筆資金購買跨地域復(fù)制許可，也無法保證順利實(shí)現(xiàn)客戶的需求。業(yè)務(wù)團(tuán)隊(duì)最終可能需要花大量時(shí)間（甚至幾個(gè)月）來編寫、完善、測試他們的工作方案。

如果選擇 Pulsar，我們可以告訴業(yè)務(wù)贊助商 “一切盡在掌握中”。由于 Pulsar 的各項(xiàng)內(nèi)置特性都已經(jīng)過測試，使用團(tuán)隊(duì)可以在短時(shí)間內(nèi)完成部署。

在這種情況下，因?yàn)槲覀儾恍枰?Kafka API 的獨(dú)有特性，所以我們沒有使用支持 Kafka 協(xié)議（KOP）的 Pulsar Broker，而是選擇 Pulsar API，因?yàn)?Pulsar API 支持所有我們需要 Kafka API 提供的功能。

決策如下： 選擇 Pulsar ，可以優(yōu)先處理業(yè)務(wù)請求，開發(fā)團(tuán)隊(duì)只專注編寫代碼，而不是解決其他問題。選擇 Pulsar 的同時(shí)，也關(guān)注 Pulsar 社區(qū)和提供商的動態(tài)。

如果采取保守決策 選擇 Kafka ，需要接受可能無法實(shí)現(xiàn)某些使用場景的事實(shí)。對于相似的使用場景，我們采取相應(yīng)解決方案。調(diào)整項(xiàng)目時(shí)間規(guī)劃，增加實(shí)行預(yù)期解決方案的時(shí)間。聯(lián)系運(yùn)營團(tuán)隊(duì)，確?？梢猿惺軋?zhí)行預(yù)期解決方案的開銷。

高級消息使用場景

假設(shè)一個(gè)公司已經(jīng)在使用多種消息和隊(duì)列系統(tǒng)。從 運(yùn)營、架構(gòu)和開銷 的角度來看，我們認(rèn)為有必要遷移到單個(gè)系統(tǒng)。同時(shí)，我們也希望降低運(yùn)營成本。

數(shù)據(jù)架構(gòu)師團(tuán)隊(duì)在和股東以及業(yè)務(wù)部門詳細(xì)討論了當(dāng)前和未來需求后，給出的結(jié)論是，Pulsar 和 Kafka 各有優(yōu)勢。

隊(duì)列和消息

最大的難題是 RabbitMQ 系統(tǒng)。我們使用 RabbitMQ 發(fā)送太多消息，RabbitMQ 已經(jīng)無法滿足需求。我們調(diào)整了 RabbitMQ 的代碼，將消息緩沖在內(nèi)存中，并繼續(xù)創(chuàng)建新集群來處理負(fù)載。但是我們需要的不是變通方法，而是一個(gè)能夠處理大規(guī)模消息的系統(tǒng)。

數(shù)據(jù)架構(gòu)師在研究這一使用場景時(shí)，得出結(jié)論： 新系統(tǒng)必須可以同時(shí)處理消息流模型和隊(duì)列模型 。我們不僅需要繼續(xù)使用 RabbitMQ 處理消息，也需要更高級的消息技術(shù)。

Kafka 擅長消息傳遞，也可以處理大規(guī)模消息流，但是無法處理隊(duì)列。開發(fā)團(tuán)隊(duì)可以嘗試一些解決方案，但這樣就不能實(shí)現(xiàn)使用單個(gè)系統(tǒng)的預(yù)期目標(biāo)。要處理隊(duì)列使用場景，就同時(shí)需要 Kafka 集群和 RabbitMQ 集群。Kafka 集群更像一個(gè)緩沖區(qū)，可以有效防止 RabbitMQ 集群過載。但是 Kafka 不支持原生 RabbitMQ，我們需要與提供商合作或自己編寫代碼，才可以實(shí)現(xiàn)在 Kafka 和 RabbitMQ 之間移動數(shù)據(jù)。

Pulsar 可以在同一集群中處理隊(duì)列和消息，還支持?jǐn)U展集群。Pulsar 可以將所有消息流模型和隊(duì)列模型的使用場景整合到一個(gè)集群中。用戶可以繼續(xù)使用 RabbitMQ 代碼，Pulsar 支持 RabbitMQ 連接器，或者在 broker 中使用 StreamNative 開發(fā)的  AoP（AMQP 協(xié)議處理插件） ^[6] ，該插件已獲得 Apache 許可。

如果不想繼續(xù)使用 RabbitMQ 代碼，則可以使用 Pulsar API。Pulsar API 具有和 RabbitMQ 相同的隊(duì)列功能。用戶需要對代碼進(jìn)行相應(yīng)修改，工作量取決于原代碼的結(jié)構(gòu)和細(xì)節(jié)，修改代碼后，還需要對代碼進(jìn)行評估測試。

就隊(duì)列模型和消息流模型而言，我們選擇 Pulsar。

高級保留

數(shù)據(jù)架構(gòu)師分析了數(shù)據(jù)使用情況，發(fā)現(xiàn) 99.99% 的數(shù)據(jù)在首次使用后就未被讀取。但是，他們決定采取保守策略，保留消息一周。雖然決定存儲數(shù)據(jù)一周，但我們不希望增加太多運(yùn)營成本。分層存儲可以保存數(shù)據(jù)到本地，然后卸載其他數(shù)據(jù)到 S3，降低長期保存數(shù)據(jù)的成本。

Kafka 團(tuán)隊(duì)正在開發(fā)分層存儲，但 Kafka 目前還不支持這一特性。一些服務(wù)商提供私有分層存儲，但我們不確定是否可以直接用于生產(chǎn)環(huán)境中。

分層存儲是 Pulsar 的原生特性，可以直接用于生產(chǎn)環(huán)境。目前已有多個(gè)企業(yè)在生產(chǎn)環(huán)境中部署該特性。

就分層存儲而言，我們選擇 Pulsar。Kafka 正在全力開發(fā)分層存儲，這一特性的重要性不言而喻。

路由 Topic

由于我們使用多個(gè) topic 來分解數(shù)據(jù)，我們期待新系統(tǒng)可以創(chuàng)建大量 topic。數(shù)據(jù)架構(gòu)師認(rèn)為，我們起初需要 10 萬個(gè) topic，隨著時(shí)間的推移，這個(gè)數(shù)字將會漲到 50 萬。

Kafka 集群支持創(chuàng)建的分區(qū)數(shù)量有限且每個(gè) topic 至少需要一個(gè)分區(qū)。Kafka 正在增加可支持 topic 的數(shù)量，但新特性尚未發(fā)布。另外，Kafka 沒有命名空間和多租戶，因此無法基于 topic 對資源進(jìn)行分片，十萬個(gè) topic 需要存儲在同一個(gè)命名空間中。

一些企業(yè)的確在使用 Kafka 集群存儲甚至更多的 topic，同時(shí)進(jìn)行了資源分片。但他們放棄使用單一集群，同時(shí)還需要為此支付費(fèi)用。

Pulsar 支持存儲數(shù)百萬個(gè) topic，這一功能早已發(fā)布并投入生產(chǎn)環(huán)境。Pulsar 支持命名空間和多租戶，用戶可以為每個(gè) topic 設(shè)置資源配額，進(jìn)而節(jié)約開銷。

就 topic 而言，我們選擇 Pulsar。

路由

由于我們假設(shè)該企業(yè)曾經(jīng)使用 RabbitMQ，在設(shè)計(jì)上，一般通過 broker 路由機(jī)制把 topic 上的數(shù)據(jù)轉(zhuǎn)發(fā)到不同的 topic 中。例如，有一個(gè)用于存儲世界范圍數(shù)據(jù)的 topic，而 RabbitMQ broker 把它處理成以國家為單位的 topic。

數(shù)據(jù)架構(gòu)師團(tuán)隊(duì)深入研究了如何在消息系統(tǒng)中使用單一 topic 存儲世界范圍的數(shù)據(jù)。他們發(fā)現(xiàn)當(dāng)接收數(shù)據(jù)量增大時(shí)，下游 consumer 無法繼續(xù)處理數(shù)據(jù)。對每個(gè)下游系統(tǒng)進(jìn)行反序列化、查看數(shù)據(jù)，再丟棄數(shù)據(jù)的流程繁雜，且費(fèi)時(shí)費(fèi)力。

Kafka 將所有數(shù)據(jù)存儲在單一 topic 中，但是，當(dāng) consumer 需要過濾的數(shù)據(jù)量增加或集群過載時(shí)，這個(gè)方法不可行。我們通常需要進(jìn)行水平縮放，增加 consumer 數(shù)量，才可以讀取全局 topic 并做進(jìn)一步處理。用戶只能選擇：編寫自定義 consumer /producer，編寫 Kafka Streams 程序，或使用專有 KSQL。

Pulsar 支持使用 Pulsar Functions 或自定義 consumer /producer 進(jìn)行路由，因此可以先讀取全局 topic，再將數(shù)據(jù)保存到以國家為單位的特定 topic 上。使用獨(dú)立 topic，consumer 可以按需訂閱 topic，只接收相關(guān)消息。

就路由而言，我們選擇 Pulsar。

最終決策

時(shí)間是影響最終決策的主要原因。我們是否有時(shí)間讓 Kafka 趕上 Pulsar？我們是否有時(shí)間讓數(shù)據(jù)工程師來實(shí)現(xiàn) Kafka 的解決方案？等待會讓公司錯(cuò)失良機(jī)，延緩增加新的使用場景，影響業(yè)務(wù)發(fā)展。

最終決策： 我們選擇 Pulsar。

時(shí)間充足情況下的決策： 延遲使用新架構(gòu) 。給 Kafka 半年時(shí)間，看 Kafka 是否可以在性能上趕超 Pulsar。如果可以，我們將在生產(chǎn)環(huán)境中測試這些新特性，評估穩(wěn)定性。如果 Kafka 不能讓人眼前一亮，我們?nèi)匀粫x擇 Pulsar。

結(jié)語

本文涉及的三個(gè)使用場景都是我在實(shí)際工作中遇到的，希望本文給出的解決方案可以為您提供參考，幫助您根據(jù)具體使用場景進(jìn)行技術(shù)評估。