溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“Pulsar與Kafka有哪些區別”，在日常操作中，相信很多人在Pulsar與Kafka有哪些區別問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Pulsar與Kafka有哪些區別”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
Pulsar 由 3 個主要組件組成：broker、Apache BookKeeper 和 Apache ZooKeeper。Broker 是無狀態服務，客戶端需要連接到 broker 進行核心消息傳遞。而 BookKeeper 和 ZooKeeper 是有狀態服務。BookKeeper 節點（bookie）存儲消息與游標，ZooKeeper 則只用于為 broker 和 bookie 存儲元數據。另外，BookKeeper 使用 RocksDB 作為內嵌數據庫，用于存儲內部索引，但 RocksDB 的管理不獨立于 BookKeeper。
Kafka 采用單片架構模型，將服務與存儲相結合，而 Pulsar 則采用了多層架構，可以在單獨的層內進行管理。Pulsar 中的 broker 在一個層上進行計算，而 bookie 則在另一個層上管理有狀態存儲。
Pulsar 的多層架構看起來似乎比 Kafka 的單片架構更為復雜，但實際情況卻沒這么簡單。架構設計需要權衡利弊，BookKeeper 使得 Pulsar 更具可伸縮性、操作負擔更低、速度更快，性能也更一致。在后文中，我們會就以上幾點進行詳細討論。
Pulsar 的多層架構影響到了其存儲數據的方式。Pulsar 將 topic 分區劃分為分片，然后將這些分片存儲在 Apache BookKeeper 的存儲節點上，以提高性能、可伸縮性和可用性。
Pulsar 的無限分布式日志以分片為中心，借助擴展日志存儲（通過 Apache BookKeeper）實現，內置分層存儲支持，因此分片可以均勻地分布在存儲節點上。由于與任一給定 topic 相關的數據都不會與特定存儲節點進行捆綁，因此很容易替換存儲節點或縮擴容。另外，集群中最小或最慢的節點也不會成為存儲或帶寬的短板。
Pulsar 的架構無分區，也沒有重平衡，保證了及時可伸縮性和高可用性。這兩個重要特性使 Pulsar 尤其適用于構建與關鍵任務相關的服務，如金融用例的計費平臺，電子商務和零售商的交易處理系統，金融機構的實時風險控制系統等。
通過利用性能強大的 Netty 架構，數據從 producers 到 broker，再到 bookie 的轉移都是零拷貝，都不會生成副本。這一特性對所有流用例都非常友好，因為數據直接通過網絡或磁盤進行傳輸，沒有任何性能損失。
Pulsar 的消費模型采用了流拉取的方式。流拉取是長輪詢的改進版，不僅實現了單個調用和請求之間的零等待，還可以提供雙向消息流。通過流拉取模型，Pulsar 實現了比所有現有長輪詢消息系統（如 Kafka）都低的端到端延遲。
在評估特定技術的操作簡便性時，不僅要考慮初始設置，還要考慮長期維護和可伸縮性。需要考慮以下幾項： - 要跟上業務增長的速度，擴展集群的操作是否迅速便捷？ - 集群是否對多租戶（對應于多團隊、多用戶）開箱可用？ - 運維任務（如替換硬件）是否會影響業務的可用性與可靠性？ - 是否可以輕松復制數據以實現數據的地理冗余或不同的訪問模式？
長期使用 Kafka 的用戶會發現在運維 Kafka 時上述問題都不容易回答。其中多數任務都需要 Kafka 之外的其他工具，如用于管理集群再平衡的 cruise control，以及用于復制需求的 Kafka mirror-maker。
由于 Kafka 很難在團隊之間共享，很多機構開發了用于支持和管理多個不同集群的工具。這些工具對成功大規模使用 Kafka 至關重要，但同時也增加了 Kafka 的復雜性。最適合用來管理 Kafka 集群的工具都是商業軟件，不開源。那這就不意外了，囿于 Kafka 復雜的管理和運維，許多企業轉而采買 Confluent 的商業服務。
相比之下，Pulsar 的目標是簡化運維和可擴展。根據 Pulsar 的性能，我們對以上問題作出如下回答：
要跟上業務增長的速度，擴展集群的操作是否迅速便捷？
Pulsar 的自動負載均衡功能可以自動并立即使用集群中新加的計算和存儲能力。這使得 broker 之間可以遷移 topic 來平衡負載，新 bookie 節點可以立即接受新數據分片的寫入流量，而無需手動重新平衡或管理 broker。
集群是否對多租戶（對應于多團隊、多用戶）開箱可用？
Pulsar 采用分層架構，租戶和命名空間能夠與機構或團隊形成良好的邏輯映射，Pulsar 通過這種相同的機構支持簡易 ACL、配額、自主服務控制，甚至也支持資源隔離，從而允許集群使用者輕松管理共享集群。
運維任務（如替換硬件）是否會影響業務的可用性與可靠性？
替換 Pulsar 的無狀態 broker 操作簡單，無需擔心數據丟失。Bookie 節點會自動復制全部未復制的數據分片，而且用于解除和替換節點的工具為內置工具，很容易實現自動化。
是否可以輕松復制數據以實現數據的地理冗余或不同的訪問模式？
Pulsar 具有內置的復制功能，可用于無縫跨越地理區域同步數據或復制數據到其他集群，以實現其他功能（如災備、分析等）。
相比于 Kafka，Pulsar 的特性為流數據的現實問題提供了更完整的解決方案。從這個角度看，Pulsar 擁有更完善的核心功能集，使用簡單，因而允許使用者和開發者專注于業務的核心需求。
由于 Pulsar 是一項比 Kafka 更新的技術，其生態系統還不夠完善，文檔和培訓資源也仍在補充中。但是，這也正是在過去一年半的時間里，Pulsar 的主要發展方向。以下為一些主要成果：
Pulsar Summit Virtual Conference 2020，Pulsar 的首次全球峰會 ，來自超過 25 個機構的演講者共計進行了 36 次分享，注冊參會者超過 600 人。
2020 年已原創 50+ 視頻及培訓版塊。
Pulsar 每周直播及互動教程。
業內領先講師進行專業培訓。
與戰略商業伙伴每月舉辦一次網絡研討會。
發布涂鴉、OVHCloud、騰訊、Yahoo!Japan 等用例的白皮書。
更多關于 Pulsar 文檔和培訓的內容，參閱 StreamNative 的 Resources 網站。
Kafka 和 Pulsar 都可以提供企業級支持。多個大型供應商（包括 Confluent）為 Kafka 提供了企業級支持。StreamNative 為 Pulsar 提供了企業級支持，但 StreamNative 仍在起步發展階段。StreamNative 為企業提供全面托管的 Pulsar 云端服務及 Pulsar 企業級支持服務。
StreamNative 團隊在消息和事件流方面經驗豐富，成長迅速。StreamNative 由 Pulsar 和 BookKeeper 核心成員創建。在 StreamNative 團隊的幫助下，Pulsar 生態系統在短短幾年時間里突飛猛進，如得到了戰略合作伙伴的支持，這種支持將會進一步促進 Pulsar 的發展，以滿足大量用例的需求（這部分內容將在下篇文章中詳細介紹）。
Pulsar 最近的重大進展如 KoP（即 Kafka-on-Pulsar），由 OVHCloud 和 StreamNative 于 2020 年 3 月推出。通過向現有 Pulsar 集群添加 KoP 協議處理程序，用戶可以將現有的 Kafka 應用程序和服務遷移到 Pulsar，而無需修改代碼。在 2020 年 6 月，中國移動與 StreamNative 宣布推出另一重要產品 —— AoP（即 AMQP on Pulsar）。AoP 使得 RabbitMQ 應用程序可以利用 Pulsar 的特性，如使用 Apache BookKeeper 和分層存儲支持無限事件流存儲等。這部分內容會在下篇中詳細介紹。
隨著 Pulsar 用戶迅速增加，Pulsar 社區已經發展成為大型、高度參與、用戶全球化的社區。Pulsar 生態系統中周邊工具插件數量迅速增長，活躍的 Pulsar 社區起到了極其重要的推動作用。在過去的六個月里，Pulsar 生態系統中官方支持的 connector 數量急劇增長。
為了進一步支持 Pulsar 社區的發展，StreamNative 不久前推出了 StreamNative Hub。StreamNative Hub 支持用戶查找、下載集成。這一平臺將有助于加速 Pulsar connector 和插件生態系統的發展。
Pulsar 社區也一直在積極地與其他社區密切合作，以整合雙方的項目。例如，Pulsar 社區與 Flink 社區一直在共同開發 Pulsar-Flink Connector （FLIP-72 的一部分）。通過 Pulsar-Spark Connector，用戶可以使用 Apache Spark 處理 Apache Pulsar 中的處理事件。SkyWalking Pulsar 插件集成了 Apache SkyWalking 和 Apache Pulsar，允許用戶通過 SkyWalking 追蹤消息。除此之外，Pulsar 社區還有很多正在進行中的集成項目。
Pulsar 目前官方支持 7 種語言，而 Kafka 只支持 1 種語言。Confluent 博客指出 Kafka 目前支持 22 種語言，但是，官方客戶端并不能支持這么多種語言，而且一些語言已經不再維護。根據最新統計，Apache Kafka 官方客戶端只支持 1 種語言，而 Apache Pulsar 官方客戶端支持 7 種語言。 - Java - C - C++ - Python - Go - .NET - Node
Pulsar 還支持由 Pulsar 社區開發的諸多客戶端，如： - Rust - Scala - Ruby - Erlang
Pulsar 和 Kafka 都被廣泛用于多個企業用例，也各有優勢，都能通過數量基本相同的硬件處理大流量。部分用戶誤以為 Pulsar 使用了更多的組件，因此需要更多的服務器來實現與 Kafka 相匹敵的性能。雖然這種想法的確適用于一些特定硬件配置，但 在多數同等資源配置中，Pulsar 優勢更加明顯，可以以相同的資源實現更多性能。
舉例來說，Splunk 最近分享了他們選擇 Pulsar 而非 Kafka 的原因，其中提到由于分層架構，Pulsar 幫助他們將成本降低了 1.5 - 2 倍，延遲降低了 5 - 50 倍，運營成本降低 2 -3 倍（幻燈片第 34 頁）。Splunk 團隊發現這是因為 Pulsar 可以更好地利用磁盤 IO，降低 CPU 利用率，同時更好地控制內存。
騰訊等公司選擇 Pulsar 在很大程度上是因為 Pulsar 的性能屬性。在騰訊計費平臺白皮書中提到，騰訊計費平臺擁有百萬級用戶，管理約 300 億第三方托管賬戶，目前正在使用 Pulsar 處理每天數億美元的交易。考慮到 Pulsar 可預測的低延遲、更強的一致性和持久性保證，騰訊選擇了 Pulsar 而非 Kafka。
Apache Pulsar 支持四種不同訂閱模式。單個應用程序的訂閱模式由排序和消費可擴展性需求決定。以下為這四種訂閱模式及相關的排序保證：
獨占和災備訂閱模式都在分區級別支持強排序保證，支持跨 consumer 并行消費同一 topic 上的消息。
共享訂閱模式支持將 consumer 的數量擴展至超過分區的數量，因此這種模式非常適合 worker 隊列用例。
鍵共享訂閱模式結合了其他訂閱模式的優點，支持將 consumer 的數量擴展至超過分區的數量，也支持鍵級別的強排序保證。
更多關于 Pulsar 訂閱模式和相關排序保證的信息，參閱訂閱。
Pulsar 和 Kafka 對于內置流處理的目標不盡相同。針對較為復雜的流處理需求，Pulsar 集成了 Flink 和 Spark 這兩個成熟的流處理框架，并開發了 Pulsar Functions 來處理輕量級計算。Kafka 則開發并使用 Kafka Streams 這一成熟的流處理引擎。
但是，使用 Kafka Streams 要更復雜一些。用戶需要弄清楚使用 KStreams 應用程序的場景及方法。并且，對于大多數輕量級計算用例來說，KStreams 過于復雜。
另外，Pulsar Functions 輕松實現了輕量級計算用例，并允許用戶創建復雜的處理邏輯，而無需部署單獨的臨近系統。Pulsar Functions 還支持原生語言和易于使用的 API。用戶不必學習復雜的 API 就可以編寫事件流應用程序。
一份最近提交的 Pulsar 改進方案（Pulsar Improvement Proposal，PIP）中介紹了 Function Mesh。Function Mesh 是無服務器架構的事件流框架，結合使用多個 Pulsar Functions 以便于構建復雜的事件流應用程序。
目前，Pulsar 通過 broker 端去重支持 exactly-once producer。這個重大項目正在開發中，敬請期待！
Pulsar 自 PIP-31 起支持事務型消息流，目前仍在開發中。這一特性提高了 Pulsar 的消息傳遞語義和處理保證。在交易型流中，每條消息只會寫入一次、處理一次，即便 broker 或 Function 實例出現故障，也不會出現數據重復或數據丟失。交易型消息不僅簡化了使用 Pulsar 或 Pulsar Functions 向應用程序寫入的操作，還擴展了 Pulsar 支持的用例的范圍。關于 Pulsar 這一特性的開發進展順利，將會在 Pulsar 2.7.0 版本中發布，預計發布時間 2020 年 9 月。
Pulsar 旨在支持用戶消費數據。應用程序可以需要選擇使用原始數據或壓縮數據。Pulsar 通過這種按需選擇的方式，允許未壓縮數據通過保留策略控制無限制增長，但仍允許通過周期性壓縮生成最新的實物化視圖。內置的分層存儲特性支持 Pulsar 從 BookKeeper 卸載未壓縮數據到云存儲中，因而降低長期存儲事件的成本。
相比于 Pulsar，Kafka 不支持用戶使用原始數據。并且，在數據壓縮后，Kafka 會立即刪除原始數據。
雅虎最初開發 Pulsar 將其同時用作發布/訂閱消息的平臺（又稱云消息）。但是，Pulsar 現在不僅是一個消息平臺，還是統一的消息和事件流平臺。Pulsar 引入了一系列工具，作為平臺的一部分，為構建事件流應用程序提供必要的基礎。Pulsar 支持以下事件流功能：
無限事件流存儲支持通過向外擴展日志存儲（通過 Apache BookKeeper）大規模存儲事件，并且 Pulsar 內置的分層存儲支持高質量、低成本的系統，如 S3、HDFS 等。
統一的發布/訂閱消息模型支持用戶輕易地向應用程序中添加消息。這一模型可以根據流量和用戶需求進行伸縮。
協議處理框架、Pulsar 與 Kafka 的協議兼容性（通過 Kafka-on-Pulsar，KoP），以及 AMQP（通過 AMQP-on-Pulsar）支持應用程序使用任一現有協議在任一位置生產和消費事件。
Pulsar IO 提供了一組與大型生態系統集成的 connector，允許用戶從外部系統獲取數據，而無需編寫代碼。
Pulsar 與 Flink 的集成支持全面的事件處理。
Pulsar Functions 提供了一個輕量級無服務器框架來處理到達的事件。
Pulsar 與 Presto 的集成（Pulsar SQL）支持數據專家和用戶使用 ANSI 兼容的 SQL 來分析數據和處理業務。
通過 Pulsar IO、Pulsar Functions、Pulsar Protocol Handler，Pulsar 具有全面路由的功能。Pulsar 的路由功能包括基于內容的路由、消息轉換，和消息擴充。
和 Kafka 相比，Pulsar 的路由能力更穩健。Pulsar 為 connector 和 Functions 提供了更靈活的部署模型。簡易的部署可以在 broker 中運行。另外，部署也可以在專用的節點池中運行（類似于 Kafka Streams），節點池支持大規模擴展。Pulsar 還與 Kubernetes 原生集成。另外，可以將 Pulsar 配置為以 pod 的形式來調度 Functions 和 connector 的工作負載，充分利用 Kubernetes 的彈性。
如前文所述，Pulsar 最初的開發目的是作為統一的消息發布/訂閱平臺。Pulsar 團隊深入了解了現有開源消息系統的優缺點，并基于團隊的經驗設計了 Pulsar 的統一消息模型。Pulsar 消息 API 同時支持隊列和流。不僅可以實現 worker 隊列，以輪詢的方式將消息發送給相互競爭的 consumer（通過共享訂閱），還可以通過兩種方式支持事件流：一是基于分區（通過災備訂閱）中消息的順序；二是基于鍵范圍（通過鍵共享訂閱）中消息的順序。用戶可以在同一組數據上構建消息應用程序和事件流應用程序，而無需復制數據到不同數據系統。
另外，Pulsar 社區還在嘗試使 Apache Pulsar 可以原生支持不同的消息協議（如 AoP、KoP），以擴展 Pulsar 的功能。
到此，關于“Pulsar與Kafka有哪些區別”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
