我撰写了这篇文章，以帮助您了解这两种解决方案的主要异同。我们将对 Kafka 和 Pulsar 进行比较，重点关注以下几个方面：

最后，我希望您能更清楚地了解每个平台的独特功能，以及哪个平台最适合贵组织的需求。

Kafka 是一个分布式事件流平台，旨在处理高速、大容量和容错数据流。它最初由 LinkedIn 开发，后来捐赠给了 Apache 软件基金会。Kafka 已迅速成为构建实时数据管道、事件驱动架构和微服务应用程序的热门选择。

Pulsar 是一个分布式消息传递系统，旨在处理高性能、低延迟的消息传递和数据流。Pulsar 最初由雅虎创建，后来捐赠给了阿帕奇软件基金会，目前正在成为构建实时数据管道和事件驱动架构的有力选择。

现在我们来回顾一下 Pulsar 和 Kafka 的架构，以了解它们的异同。

在高层次上，Kafka 架构由三个主要元素组成：生产者、消费者和经纪人。生产者生成数据并发送给经纪商，而消费者则读取经纪商摄取的数据。

经纪人在 Kafka 集群上运行，而生产者和消费者则与系统完全分离。每个经纪商将生产者发送的实际数据存储在主题（属于同一组/类别的消息集合）中。这些主题可分为多个分区进行优化。数据分区具有容错、可扩展性和并行性等优点。此外，每个代理可能只包含一个主题的部分分区，其余分区则分配给其他代理。这种方法有助于平衡经纪人之间的工作量。为了提高可靠性，可以将 Kafka 集群配置为不同主题的副本，从而在代理不可用时限制停机时间。

在上图中，你还可以看到一个 ZooKeeper 组件，它负责诸如

计划完全移除 ZooKeeper 依赖关系。(预计将于 2024 年 4 月发布）开始完全移除对 ZooKeeper 的依赖。取而代之的是一种名为 KRaft 的新机制（实际上它已经可以投入生产）。KRaft 无需在每个 Kafka 集群旁边运行一个 ZooKeeper 集群，而是将元数据管理的责任转移到 Kafka 本身。这简化了架构，降低了操作复杂性，并提高了可扩展性。

还计划为 Kafka 引入分层存储方法的分层存储方法。本地层将使用 Kafka Brokers 上的本地磁盘来存储数据。其设计目的是短时间（如几小时）保留数据。与此同时，远程存储将使用 Hadoop Distributed File System（HDFS）和 Amazon S3 等系统来长期存储数据（数天、数月等）。

与 Kafka 类似，Pulsar 的架构包括经纪人、生产者和消费者。经纪商在 Pulsar 集群上运行，而生产者和消费者则与系统完全分离。每个经纪人管理生产者在主题中发送的实际数据。就像 Kafka 的情况一样，这些主题可以划分成许多分区，从而提供容错、可扩展性和并行性等优势。

ZooKeeper 也出现在 Pulsar 的架构中。它被用于各种任务，包括配置管理、节点之间的协调以及维护 Pulsar 集群的元数据。如前所述，Kafka 正在从 ZooKeeper 迁离，取而代之的是 KRaft。Pulsar 并没有让 ZooKeeper 退出其架构，但它确实提供了替代方案：本地内存、 RocksDB和 etcd(注意，前两者只适用于独立的 Pulsar 或单节点 Pulsar 集群）。

与 Kafka 相比，Pulsar 最大的不同在于它将存储层和服务层分开。在 Pulsar 的架构中，Broker 处理消息路由和传递，而 Apache BookKeeper 处理长期存储。具体来说，生产者发送的每条消息都会被写入 BookKeeper 记事本中保存。这种分层存储方法意味着 Pulsar 的架构比 Kafka 的架构更复杂--有更多的组件需要管理（至少目前是这样；但如前所述，Kafka 也将引入分层存储方法）。另一方面，这种解耦意味着你可以独立扩展存储层和服务层。

Pulsar 和 Kafka 在存储和消息消耗模式、延迟、吞吐量、耐用性和可扩展性方面相比如何？

这两种解决方案在信息消耗和存储模式方面存在很大差异。

Kafka 的基于日志的存储模型为每个主题分区使用一个仅有附加文件的日志文件，信息按顺序写入并存储在磁盘上。读取是顺序的，从偏移量开始（注意，消费者负责管理他们的偏移量）。写入会追加到日志的末尾。对于消息消费，Kafka 的拉动模型涉及消费者从代理处轮询新消息。

相比之下，Pulsar 的分层存储模型将信息分成较小的段，并将其存储在多个 BookKeeper 分类账（账本）中。值得注意的是，信息段也可以 卸载到长期存储解决方案如亚马逊 S3 或谷歌云存储。信息通过基于推送的模式消耗。

就这些差异谈几点看法：

毫无疑问，Kafka 和 Pulsar 都是高性能的分布式流媒体和消息传递平台。很难（甚至不可能）说哪一个在延迟和吞吐量方面更胜一筹。一些基准测试表明 Pulsar 性能更好，而 其他基准则显示 Kafka 更胜一筹。

尽管如此，基于推送的消息传递系统和分层存储模型（如 Pulsar）确实有助于缩短延迟时间，因为它们能促进数据组织，提高存储资源的使用效率，并能加快数据检索速度。

相反，Kafka 依靠的是连续轮询过程，即客户端在设定的时间间隔内重复请求数据。在消息量较少的时期，这可能会导致较高的延迟，因为客户端可能会在轮询间隔之间空闲等待。

不过，Pulsar 相对于 Kafka 的理论优势在实践中是否成立取决于具体的工作负载和使用模式。最好还是进行自己的基准测试，以确定这方面的情况。

Kafka 和 Pulsar 提供耐久性功能，以确保高可用性和系统弹性。这两种解决方案都允许您无限期地存储消息，这对于发生故障或灾难时的恢复和连续性至关重要。此外，Kafka 和 Pulsar 还支持地理复制（在不同数据中心甚至不同地区之间）。Kafka 支持主题级别的复制；而 Pulsar 则提供主题和命名空间级别的复制。值得注意的是，与 Kafka 相比，Pulsar 在地理复制数据时需要额外的“全局 ”ZooKeeper 集群，这增加了复杂性。

Kafka 和 Pulsar 都是高度可扩展的平台。与 Kafka 相比，Pulsar 的分段、分层架构可能会在一定程度上增加灵活性并提高可扩展性（因为 Pulsar 的数据层和服务层是独立扩展的）。

迄今为止，Kafka 在可扩展性方面的最大瓶颈是 Apache ZooKeeper 的使用。ZooKeeper 存储 Kafka 的元数据，包括主题、分区、副本及其配置的信息。ZooKeeper 限制了 znode（ZooKeeper 中的数据节点）中可存储数据的最大大小。这种数据大小限制间接限制了 Kafka 可管理的分区数量（每个集群大约可管理 500K 个分区）。

不过，如前所述，Kafka 正在移除对 ZooKeeper 的依赖，取而代之的是 KRaft。换句话说，ZooKeeper 对每个集群施加的 500K 分区限制将不复存在。KRaft 还带来了其他好处——例如，它使控制器的故障切换几乎瞬时完成，并简化了 Kafka 的架构、部署和配置。

无论是否使用 KRaft，Kafka 都能毫无困难地扩展到绝大多数用例。Pulsar 也非常适合处理大规模场景。事实上，除非您处理的是超大规模场景（PB 级数据和每天数万亿条消息），否则您不太可能在使用这两个工具中的任何一个时遇到严重的可扩展性问题。即便如此，通过重新架构或优化 Kafka 或 Pulsar 部署，你也不可能无法解决这些问题。

到目前为止，我们已经看到 Kafka 和 Pulsar 是高性能、高扩展性和持久性的解决方案。然而，在选择数据流平台时，并不能只考虑延迟和规模。有鉴于此，让我们来比较一下 Kafka 和 Pulsar 的开发人员体验和生态系统。

您需要了解一些背景知识，才能充分理解 Kafka 和 Pulsar 社区和在线资源之间的差异。

Kafka 于 2012 年成为正式的 Apache 软件基金会项目，而 Pulsar 则在四年后的 2016 年达到了同样的里程碑。此外，Kafka 的开源特性促进了其 迅速普及实时事件流解决方案的需求激增。

这在很大程度上说明了 Kafka 在以下方面比 Pulsar 更强的优势。话虽如此，Pulsar 的社区正在经历增长，这始终是一个项目未来发展的良好指标。

总之，不可否认的是，在文档、在线资源和社区方面，Kafka 比 Pulsar 更胜一筹。Kafka 也更受欢迎（从 GitHub 的统计数据来看），学习起来也更容易（尽管 Kafka 和 Pulsar 都很难掌握）。

总的来说，在 CLI 工具方面，Kafka 和 Pulsar 似乎不相上下。两者都提供 CLI，允许你管理 Kafka/Pulsar 部署并与之交互。当然，在使用这些 CLI 所能做的事情方面也存在一些差异（其中一些差异源于 Kafka 和 Pulsar 是不同的平台，具有一些不同的功能）。例如 卡夫卡 CLI为管理消费者组提供了更好、更详细的命令，而 Pulsar 的 CLI工具允许你管理包（Kafka 的 CLI 无法做到这一点）。

Kafka 和 Pulsar 都通过其客户端库支持多种编程语言。Kafka 在支持的语言数量上略胜一筹，这主要是由于其存在时间较长，应用范围较广，因此开发了更多的第三方客户端库。详情请参见下一节。

Kafka 提供 Java 和 Scala 官方客户端库。Confluent（由 Apache Kafka 的创建者创立）提供了其他一些官方支持的客户端，针对 C/C++、C#/.NET、Python、Go 和 Node.js。同样，Pulsar 也有针对 Java、C/C++、C#/.NET、Python、Go 和 Node.js 的官方客户端库。从本质上讲，Pulsar 和 Kafka 通过其官方客户端库针对的是相同的编程语言（唯一明显的区别是 Kafka 官方客户端支持 Scala，而 Pulsar 并不支持 Scala）。

除了这些官方客户端，还有许多第三方 Pulsar 和 Kafka 客户端库，其中大部分是开源项目。Kafka 稍占优势，因为你可以找到 PowerShell、Perl 和 Swift 的 Kafka 客户端（这些语言没有 Pulsar 客户端库）。

请注意，Kafka 和 Pulsar 还提供一些与语言无关的客户端。例如，Pulsar 提供 REST 和 WebSocket 客户端，而 Kafka 则提供多个 HTTP 代理客户端（包括官方客户端和社区客户端）。了解更多有关 Kafka 客户端和 Pulsar 客户端.

与 Pulsar 相比，Kafka 拥有更大的生态系统。通过连接器 Kafka Connect 框架让你可以轻松地将数据从其他系统摄取到 Kafka，并将数据从 Kafka 主题流式传输到不同的目的地。目前已有数百种针对不同类型系统的连接器，如数据库（如 MongoDB）、存储系统（如 Azure Blob Storage）、消息系统（RabbitMQ、JMS）等。

与此同时，虽然 Pulsar 的生态系统不如 Kafka 成熟，但它仍然提供了大量、多样的连接器，并与 Aerospike、Datadog 和 RabbitMQ 等其他系统集成。

在内置流处理功能方面，Kafka 比 Pulsar 更胜一筹。其 卡夫卡流库允许您构建 实时流处理应用程序Kafka Streams 库允许你构建实时流处理应用程序，并具有连接、聚合、窗口和精确一次处理等功能。相比之下，Pulsar 只通过 脉冲星函数接口为流处理提供基本功能，适用于简单的回调。除了内置的流处理功能，Kafka 和 Pulsar 还能与 Apache Flink、Apache Storm 和 Apache Beam 等流处理解决方案集成。

本节比较了 Kafka 和 Pulsar 的许可条款、商业支持选项、部署模式和托管服务产品。

如您所见，Kafka 和 Pulsar 在许可方面没有区别。这两个平台都是开源的--它们都使用 Apache License 2.0.

尽管如此，如果不想自己管理 Kafka/Pulsar，也有第三方供应商提供商业支持。不过，值得指出的是，与 Pulsar 相比，Kafka 的商业支持更为成熟和广泛。有关这方面的更多信息，请参见下一节。

Kafka 和 Apache 可以通过多种方式灵活部署，如内部部署、云部署、使用 Docker 或 Kubernetes。此外，许多托管服务提供商都支持 Kafka 和 Pulsar，这可以简化这些系统的部署、扩展和管理。不过，需要注意的是，Kafka 供应商的数量更多（也更知名）。这并不令人意外，毕竟 Kafka 的历史更悠久，与 Pulsar 相比更早（也更广泛）得到采用。

在选择数据流平台时，安全性往往是首要考虑的问题。那么 Pulsar 和 Kafka 相比如何呢？

Kafka 和 Pulsar 都提供可靠的安全功能，如加密和强大的身份验证和授权机制。

在某些方面，Pulsar 具有优势：例如，它原生支持端到端加密，并内置审计日志。这并不是说 Pulsar 本身就比 Kafka 更安全，也不是说 Kafka 缺乏关键的安全功能，但值得注意的是，Pulsar 提供了一些额外的安全机制，可能会派上用场。

正如我们所看到的，Kafka 和 Pulsar 都是数据流平台，具有一些相似的特点。它们都是高吞吐量、低延迟、持久耐用和高度可扩展的解决方案，并通过官方和第三方客户端 SDK 实现了良好的编程语言覆盖。

不过，它们之间也有很多不同之处。例如，Pulsar 具有一些额外的安全功能（如内置审计日志）。它还采用分层架构，将存储层与服务层分开。这为您提供了灵活性，因为这些层可以根据需求独立扩展。

另一方面，Kafka 的架构没那么复杂，组件较少。此外，与 Pulsar 相比，Kafka 拥有更强大、更成熟的连接器和集成生态系统，并提供更丰富的流处理功能。Kafka 还拥有一个规模更大的社区，而且它在超大规模的实战中得到了 Netflix 和 LinkedIn 等巨头更广泛的检验。

Kafka 或 Pulsar 是否是流使用案例的最佳选择，最终取决于您的决定。

编译丨闻数起舞

来源丨toutiao.com/article/7296206768948970018/?log_from=13407589252bf_1699871003006