閱讀本文需要約 10 分鐘。
Apache Kafka 是一個存在已久的大規(guī)模分布式消息收發(fā)系統(tǒng)，它在 2011 年由 LinkedIn創(chuàng)建，在當時是大多數(shù)對性能要求嚴格的大規(guī)模消息傳遞需求的唯一選擇。每天需傳遞數(shù)百萬條消息，這樣的消息收發(fā)規(guī)模確實很龐大（2018 年 Twitter 推文平均每天 500 萬條，用戶數(shù)平均每天為 1 億）。那時，我們沒有這樣的 MOM 系統(tǒng)來處理大型用戶群的分組功能。因此，當時 Kafka 是大多數(shù)大牌公司 LinkedIn、Yahoo、Twitter、Netflix 和 Uber 的僅有選擇。
2019年情況發(fā)生了巨變，每日消息增量高達數(shù)十億，因此需要相應擴展平臺支持，以滿足持續(xù)增長的需求。為了做到這一點，消息傳遞系統(tǒng)需要在不影響客戶的情況下持續(xù)無縫地擴展。
Kafka 在擴展方面存在很多問題，并且它的系統(tǒng)也較難管理。 喜歡 Kafka 的人可能會對這種說法頗有微詞，這并非出于主觀臆斷，我本身也是 Kafka 的粉絲，但客觀的說，隨著世界范圍內(nèi)新工具的不斷創(chuàng)新，它們與舊工具相比顯而易見的是，人們往往還是覺得新工具似乎更加便捷，而舊工具更難以管理和處理。這是問題的本質(zhì)。
一款新的產(chǎn)品應運而生 —— 它就是 “Apache Pulsar” ！
雅虎于 2013 年創(chuàng)建了 Pulsar ，并于 2016 年把 Pulsar 捐給了 Apache 基金會。Pulsar 現(xiàn)已成為 Apache 的頂級項目，并且取得較大成功。 現(xiàn)在雅虎和 Twitter 都是 Pulsar 的用戶，雅虎每天發(fā)送 1000 億條消息，其中主題消息超過了 2 億條 —— 消息數(shù)之大，讓人難以置信。
接下來我們了解下 Kafka 現(xiàn)存的問題以及 Pulsar 的解決方案。
Kafka 要進行擴展是很困難的，這是因為 Kafka 將數(shù)據(jù)存儲在 broker 中的方式是消息傳遞持久性存儲的分布式日志的方式。脫離另一個 broker 意味著它必須完全復制主題分區(qū)和副本，所以完成 broker 脫離需要額外的時間。
更改分區(qū)大小以獲得更多的存儲空間可能會因與消息索引沖突而破壞消息順序。如果消息順序是主要問題，那么這一點至關重要。
如果分區(qū)副本不處于 ISR（同步）狀態(tài)，那么 leader 選取可能會紊亂?；旧?，當原始主分區(qū)失敗時，至少應該有一個 ISR 副本被選為租用，但是這點并不能完全保證。有一個設置可以禁用此功能，但如果啟用了此功能，則非 ISR 副本將被選為 leader，這比沒有 leader 分區(qū)的服務中斷更糟糕，因為這會導致更糟糕的情況。
理想情況下，你必須首先規(guī)劃和計算 broker、主題、分區(qū)和復制副本的數(shù)量（這符合計劃中的未來使用增長），以避免出現(xiàn)擴展問題，但現(xiàn)在，面對不可預測的流量需求和高峰，很難再進行規(guī)劃。
Kafka 集群的再平衡可能會影響關聯(lián)的生產(chǎn)者和消費者的性能。
Kafka 主題可能會在失敗的情況下丟失消息（特別是在第 3 點）。
使用 offsets 會比較痛苦，因為 Kafka 是愚蠢的（“愚蠢”的用詞來自于體系結(jié)構(gòu)概念“愚蠢 broker 和智能客戶”）。
如果使用率很高，則必須盡快刪除舊消息以避免磁盤空間問題。
Kafka 的本地跨區(qū)域地理復制機制（MirrorMaker）問題是一個大家比較熟知的問題，即使是在兩個數(shù)據(jù)中心內(nèi)這個問題也依然存在。因此，甚至 Uber 也創(chuàng)建了另一個解決方案來解決這個問題，并將其稱為 uReplicator 作為問題案例。
如果需要，你必須使用另一個實時事件分析器工具，如 Apache Storm、Apache Heron 或 Apache Spark，這也應該有助于支持傳入流量速率。
Kafka 沒有完全隔離租戶的原生多租戶功能，而是通過使用主題授權(quán)等安全功能來完成的。
當然，在生產(chǎn)環(huán)境中，架構(gòu)師和工程師有辦法解決上述問題；但是在平臺/解決方案或站點可靠性上，這是個讓人頭疼的問題，這并不像在代碼邏輯中修復邏輯，然后將打包的二進制文件部署到生產(chǎn)環(huán)境中那么簡單。
現(xiàn)在，我們來聊聊 Pulsar，這個競爭領域中的領跑者。
什么是 Apache Pulsar？
Apache Pulsar 是一個開源分布式 pub-sub 消息系統(tǒng)，最初由雅虎創(chuàng)建。 如果你了解 Kafka，Pulsar 在本質(zhì)上和 Kafka 很像。
Pulsar 性能
Pulsar 表現(xiàn)最出色的就是性能，Pulsar 的速度比 Kafka 快得多，德克薩斯州一家名為 Gigaom 的技術(shù)研究和分析公司進行的性能比較很好地證明了這一點。
與 Kafka 相比，Pulsar 的速度大約提高了 2.5 倍，延遲時間縮短了40％。 是不是很棒？ 當然。
（來源請點擊https://streaml.io/pdf/Gigaom-Benchmarking-Streaming-Platforms.pdf）
請注意，此性能比較是針對 1 個分區(qū)的 1 個主題，其中包含 100 字節(jié)消息，其中 Pulsar 每秒可發(fā)送 220,000+ 條消息，如下所示。
這點 Pulsar 做的確實很棒！
就沖這一點，放棄 Kafka 而轉(zhuǎn)向 Pulsar 絕對不虧，接下來我繼續(xù)介紹的內(nèi)容也進一步佐證了這個觀點。
Apache Pulsar 的優(yōu)勢和特點
Pulsar 既可以像 Kafka 那樣按照基于 offset 的單分區(qū)只被一個consumer順序消費的方式工作，也可以按照傳統(tǒng)消息隊列的單分區(qū)被多個consumer并發(fā)消費的方式工作。這是 Pulsar 的一大優(yōu)勢。
Pulsar 具有不同的數(shù)據(jù)持久性體系結(jié)構(gòu)。Pulsar 沒有像 Kafka 那樣在本地 broker 中使用日志文件，而是將所有主題數(shù)據(jù)存儲在由 Apache BookKeeper 提供支持的專用數(shù)據(jù)層中作為數(shù)據(jù)分類賬。簡單地說 BookKeeper 是一種擴展性強、容錯和低延遲的存儲服務，并且針對實時持久的數(shù)據(jù)工作負載進行了優(yōu)化。因此，BookKeeper 保證了數(shù)據(jù)的可用性，這與 Kafka 日志文件可能出現(xiàn)的問題不同，Kafka 日志文件駐留在各個 broker 以及災難性服務器故障中。由于這個有保證的持久層，Pulsar 帶來了另一個優(yōu)勢，即“ Broker 程序是無狀態(tài)的”。這與 Kafka 相比有很大的不同?，F(xiàn)在真正的優(yōu)勢是，Pulsar broker 可以無縫地橫向擴展以滿足不斷增長的需求，因為它沒有主題分區(qū)數(shù)據(jù)加載或同步，就像 Kafka 在拆分新 broker 時所做的那樣。
如果一個 Pulsar broker 失效了怎么辦？主題將立即重新分配給另一個 broker，這是可能的，因為 broker 的磁盤中沒有主題數(shù)據(jù)，服務發(fā)現(xiàn)將處理發(fā)布者/消費者。
Kafka 需要清除舊數(shù)據(jù)才能使用磁盤空間； 與 Kafka 不同，Pulsar 將主題數(shù)據(jù)存儲在一個分層結(jié)構(gòu)中，你可以在該結(jié)構(gòu)中連接其他磁盤或 Amazon S3，以無限制地擴展和卸載主題數(shù)據(jù)存儲。更酷的是，Pulsar 向消費者無縫地顯示數(shù)據(jù)，就好像它們來自一個驅(qū)動器。另一個有價值的用例是，由于不需要清除舊數(shù)據(jù)，所以你可以將這些有組織的 Pulsar 主題用作“數(shù)據(jù)湖（Data Lake）”。當然，如果需要，也可以設置 Pulsar 來清除舊數(shù)據(jù)。
Pulsar 原生支持在主題命名空間級別使用數(shù)據(jù)隔離的多租戶，而在 Kafka 中，這樣的隔離是不可能的。除此之外，為了使 Pulsar 應用程序更加可靠和安全，Pulsar 還支持細粒度訪問控制功能。
Pulsar 具有多個客戶端庫，可用于 Java、Go、Python、C++ 和 WebSocket 語言。
Pulsar 本身支持功能即服務（FaaS），這是一個非常酷的功能，類似于 Amazon Lambda，可以實時分析，聚合或匯總實時數(shù)據(jù)流。 與 Kafka 相比，這是一個很大的優(yōu)勢，因為在 Kafka 中還需要一個流處理系統(tǒng)，比如 Apache Storm，這就增添了額外的成本并且維護起來也很麻煩。 截至目前，Pulsar Functions 支持 Java 和 Python 語言，其他語言將在以后的版本中陸續(xù)得到支持。
（注： 除 Java 和 Python 語言，Pulsar Functions 目前還支持 Go 語言。）
Pulsar Functions 的用戶案例包括基于內(nèi)容的路由、聚合、消息格式化、消息清洗等。
下面是一個字數(shù)計算的示例。
Pulsar 支持多個數(shù)據(jù)接收器，用于為主要產(chǎn)品（如 Pulsar 主題本身，Cassandra，Kafka，AWS Kinesis，彈性搜索，Redis，Mongo DB，Influx DB 等）路由處理過的消息。
此外，還可以將處理過的消息流持久化到磁盤文件。Pulsar 支持使用 Pulsar SQL 以 SQL 風格方式查詢過去的消息，這可以通過使用 Presto 引擎高效地查詢 BookKeeper 數(shù)據(jù)。 Presto 是一種用于大數(shù)據(jù)解決方案的高性能分布式 SQL 查詢引擎，允許在單個查詢中查詢來自多個數(shù)據(jù)源的數(shù)據(jù)。 下面是使用 Pulsar SQL 查詢的示例，
Pulsar 另一個非常重要的功能是內(nèi)置強大的跨地域復制機制，可在不同區(qū)域的不同集群之間即時同步消息，以維護消息的完整性。 在 Pulsar 主題上生成消息時，它們首先保留在本地集群中，然后異步轉(zhuǎn)發(fā)到遠程集群。 在 Pulsar 中，啟用跨地域復制是基于每個租戶的。 只有在創(chuàng)建允許訪問兩個集群的租戶時，才能在集群之間啟用跨地域復制。
對于消息傳遞通道安全，Pulsar 支持基于 TLS 和基于 JWT token的授權(quán)機制。 因此，你可以指定誰可以發(fā)布或使用哪些主題的消息。 此外，為了提高安全性，Pulsar Encryption 允許應用程序在生產(chǎn)端加密所有消息，并在 Pulsar 傳遞加密消息到消費端時解密。Pulsar 使用應用程序配置的公鑰/私鑰對執(zhí)行加密。 具有有效密鑰的消費者才能解密加密消息。 但這會帶來性能損失，因為每條消息都需要加密和解密才能進行處理。
目前在使用 Kafka 并且希望遷移到 Pulsar 的用戶大可放心，這是因為 Pulsar 本身支持通過連接器直接使用 Kafka 數(shù)據(jù)，或者你可以很容易地將現(xiàn)有的 Kafka 應用程序數(shù)據(jù)導入到 Pulsar。
如需獲取 Pulsar 的企業(yè)服務和支持，歡迎聯(lián)系 StreamNative (info@streamnative.io）。
總結(jié)
并不是說大規(guī)模信息處理平臺使用 Kafka 不好，唯一的選擇就是 Pulsar。我要強調(diào)的是，Kafka 中存在的一些痛點 Pulsar 已經(jīng)為我們解決了，這對任何工程師或架構(gòu)師來說都是一件好事。另外，隨著雅虎和 Twitter（以及許多其他公司）已經(jīng)在使用生產(chǎn)環(huán)境消息加載，在體系架構(gòu)方面 Pulsar 在大型消息傳遞解決方案中的速度要快得多，這證明了其穩(wěn)定性和生產(chǎn)已經(jīng)為任何業(yè)務做好了準備。雖然從 Kafka 切換到 Pulsar，會經(jīng)歷一個小小的學習曲線， 但相應的投資回報率還是很客觀的！
作者：Anuradha Prasanna
翻譯：Zhanying
審校: Jennifer
編輯：Irene
