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