Pulsar 和 Kafka 的对比

Pulsar 和 Kafka 的对比

简介

最近总是看到微信上的订阅号吹 Pulsar，所以想看看它到底好在哪。

在 Google 上检索到了一家叫 pandio 的公司，他们是这么表述的:

Apache Pulsar 现在成为卓越的消息传递解决方案，在所有相关的基准测试挑战中始终击败 Kafka。 Pulsar 提供开源自由的企业级多租户、高性能消息解决方案。 Pulsar 提供了高吞吐量流与灵活的消息队列的终极竞争组合，以在一个消息传递解决方案中统一多种技术。 这种组合简化了消息流模型和消息队列的集成。 Apache Pulsar 在完全可扩展的消息传递解决方案中定期对所有竞争对手中的最低延迟进行基准测试。 以下是开发人员和项目经理更喜欢 Apache Pulsar 的 10 大原因。

1 将数据流和消息发布/订阅系统合二为一

Apache Pulsar 相对于 Kafka 的技术优势非常丰富。 这种优势在很大程度上源于 Pulsar 统一了多种消息传递技术。 首先，Apache Pulsar 提供了标准的消息队列技术，包括

• 竞争消费者
• 故障转移订阅
• 简化的消息扇出

Apache Pulsar 自动跟踪主题中的客户端读取位置。 Pulsar 将此客户端读取位置存储在其称为 Apache BookKeeper 的独特、高性能分布式存储中。 事实上，这项创新是为 Pulsar 带来竞争优势的多项创新之一。

Kafka 在这方面有缺陷，但 Apache Pulsar 可以处理传统队列系统(如 RabbitMQ)的许多适用场景。 与大多数消息传递解决方案相比，Pulsar 在一个平台上同时支持实时流和消息队列

2 在基准测试中 Apache Pulsar 始终比 Kafka 更快

对于在设计阶段选择消息系统技术栈的项目经理和开发人员来说，对速度和性能基准的批判性观察很重要。 基准示例代码是否真的与您预期的应用程序等效？ 必须准确理解基准测试的设计以及竞品消息传递平台的初始配置，以使基准与您的应用程序相关。

为了实现重要性能指标的独立基准测试，Open Messaging 创建了一个测试套件来比较 Pulsar 和 Kafka。 作为 Linux 基金会的一个项目，Open Messaging 为项目经理和开发人员提供了这一关键工具，用于客观地衡量延迟和其他对 Kafka 与 Pulsar 竞争很重要的因素。 此外，GigaOm 发布的独立研究表明，Pulsar 的吞吐量比 Kafka 好 2.5 倍，延迟降低 40%。

比较 Kafka 与 Pulsar 的延迟和性能的其他基准测试以不同方式强制同步方法来驱动相对的异步方法。 Pulsar 显然在这些基准比较中获胜。 但是，如前所述，您必须了解与您自己的应用程序的实际相关性；基准测试结果可能会受到应用程序细微差别的影响。 考虑到这一点，您将做出正确的选择。 最终，速度和可靠性决定了构建在消息平台上的应用程序的竞争成功，而 Apache Pulsar 用例始终证明其优于 Kafka 。

3 解耦存储和计算

Apache Pulsar 的多层架构实现了消息传递技术的一项重要创新。 特别是，Apache Pulsar 架构将数据处理和数据存储解耦，通常称为“存储和计算(storage and compute)”。 Pulsar 将这些层分开以实现显着的性能优势：无状态的“broker”管理数据服务，而“bookie”节点处理数据存储。 此功能允许无状态的 broker 可以水平扩展。

通过这种方式，Pulsar 优化了云原生因素并改进了其他消息传递解决方案，如 Kafka，其中存储链接到 broker，使其难以有效扩展。 相比之下，Pulsar 的解耦策略产生了许多好处。 例如，它使存储层和计算层能够相互独立地扩展。 这种弹性是云原生范式的本质。 换句话说，将弹性环境启动到容器并扩展资源以动态适应流量变化的能力是 Pulsar 利用的云计算的显着特征。

按照这些思路，Splunk 选择了 Pulsar 而不是 Kafka，因为 Pulsar 解耦存储的可扩展性使 Splunk 能够优化成本。 Pulsar 中的 Broker 进程负责所有数据移动。 生产者和消费者数据由代理进程管理。 Pulsar 的创新并置“BookKeeper Bookies”运行在各种硬件基础设施上，最终存储来自代理的数据。 Pulsar 架构中的这种性能细微差别促使 Splunk 将 Pulsar 用作企业级消息传递解决方案。

4 异地复制在 Pulsar 上是原生的

Pulsar 在 Pulsar 实例的集群之间本地复制消息，并且租户可以轻松配置为在 Pulsar 的分布式消息服务中执行此操作。 出于这个原因，Pulsar 优于 Kafka，因为 Kafka 需要另一个工具和额外的步骤来实现等效的异地复制。 这是 Pulsar 固有的地理复制功能的一个很好的例子。

跨区域复制本质上是复杂的，这是使用脉冲星流处理的一个重要原因，因为它本机最有效地处理延迟、协调和资源管理。 使用托管的 Apache pulsar 服务会更好，因为 Apache Pulsar 咨询专家会提前为您处理许多常见的操作细微差别。

Pulsar 在设计的过程中将此功能内置到应用程序的核心中。 而 Kafka 则是后期进行了补充。 这意味着牺牲了可配置性和效率。 对于 Kafka，它还需要一个单独的工具来简单地链接两个完全独立的 Kafka 集群(mirror maker)。 Pulsar 允许对单个实例进行异地复制，这提供了很大的灵活性，例如仅复制单个命名空间或租户。

使用 Kafka 进行地域复制更慢且更复杂，因为必须实施另一个名为 MirrorMaker 的工具来实现它。 MirrorMaker 跨数据中心和云区域复制消息以模拟 Pulsar 的固有功能。 这意味着 Kafka 可能足以用于备份或恢复功能，但它不是像 Pulsar 那样将消息跨地域复制到所有集群中的所有消费者的最佳选择。

5 多租户集群

Apache Pulsar 的巧妙创新包括原生多租户。 此功能为称为“租户”的多个软件应用程序提供了一个安全的共享操作环境。 Pulsar 支持的另一个基本云原生概念，多租户包括：

• Policies
• Roles
• ACL’s

以上内容可以与命名空间和主题相关联，以便明确租户之间的区别。 由于各种原因，租户可能需要这种功能区分。 软件企业中的一个租户可能使用开发命名空间，而另一个租户可能从事测试自动化工作。 大型零售商中的各个部门都可以表示为单独的租户。 银行的信用卡组可能是与贷款部门不同的一个租户。

Pulsar 的多租户功能为组织提供了运行一个全局集群的能力，该集群按部门安全地隔离数据和硬件，从而增强数据安全性——这是云的关键优先事项。 这创造了几个优点，包括：

• 开销——多租户减少了基础设施和维护计划。
• 集群大小——Pulsar 架构优化了水平和垂直可扩展性
• 复制——Pulsar 的无状态 broker 和 BookKeeper 使用 n-mesh 进行创新复制和异地复制。

使用 Kafka 时租户必须手动管理，作为跨主题和分区手动应用的内部概念。 没有任何中心概念可以使这种组织变得简单明了。

6 无状态与有状态流处理

让我们来看看 Pulsar 真正超越竞争对手的消息传递技术方面。 首先，我们需要定义几个术语：无状态和有状态。 在无状态流处理中，当前事件和任何先前的事件之间不存在依赖关系。 因此，每个传入的消息事件将在不维护有关先前消息的状态信息的情况下进行处理。 另一方面，有状态流处理意味着当前消息事件和先前事件之间的依赖关系。 在这种情况下，先前消息的状态可能会影响当前消息的处理。 为什么这很重要？

Pulsar Functions 通过支持有状态和无状态事件将流处理提升到一个新的水平，这使得消息在操作上无服务器。 您可以使用分布式状态执行转换、路由和窗口化等等。 此外，Pulsar 负责运行这些功能。 Pulsar Brokers 和 Bookies 实现了无状态流处理，这意味着除其他外，扩展是一件简单的事情。

相比之下，对于 Kafka，您必须使用 Kafka Streams SDK 自己构建函数。 然后，您必须通过将它与 Kafka 分开部署来自己操作它。 这也意味着国家也必须自己管理。 此外，由于消息和功能之间的物理距离，延迟会增加。

7 用于智能保留的存储层

虽然在 Kafka 等其他消息传递平台中，主题积压可能会扩展到无法管理的数量，但 Pulsar 通过实施分层存储架构解决了这个问题。 分层存储的功能是智能地保留较旧的消息积压，根据设计将它们从 Bookkeeper 移动到更便宜的存储。

相比之下，Kafka 可能会无限期地保留消息积压，但它使用分区来做到这一点。 分区受限于磁盘大小，因此无法捕捉真正云解决方案的本质。 开发人员将不得不设计临时代码来管理超出物理分区大小的旧消息保留。 Apache Pulsar 使用 Bookkeeper 的分布式存储来解决这个问题，让扩展存储变得容易。

分层存储允许您将积压存储无缝扩展到 AWS S3 等其他云服务。 集群存储可以无限扩展，无需进一步编码或考虑。 分层存储也不会给用户带来进一步的复杂性。 如果请求的数据恰好在 AWS S3 中，则通过相同的请求方法检索。

8 Pulsar 支持无限个主题

Kafka 的一个重要限制是它不支持大量主题。 Kafka 的设计限制包括：

• broker 是结构化的
• 存储绑定到了 broker
• 不同分区的文件进行独立处理
• 缩放时需要重新平衡数据

Apache Pulsar 解决了这些设计限制，以在支持数百万个主题。 处理入站数据和数据请求的 broker 是无状态和解耦的。 这意味着它们可以水平扩展并支持资源允许的尽可能多的主题。 支持存储层主题的是 Apache Bookkeeper 实例，它们也可以水平扩展。 Pulsar 使用 Apache ZooKeeper 为您处理这种协调，这使得您可以支持的主题数量理论上是无限的。

例如，假设您想对事件流上的客户数据进行建模。 如果您在一个独特的主题内为每个客户建模，那么事件将在 Pulsar 的架构中按时间顺序排列。 借助 Pulsar 的创新存储层，可以快速扫描数百万客户的状态，而无需额外成本、增加延迟或内存开销。 这是对 Kafka 有限主题范围的重大改进。

9 不丢失消息

消息丢失预防是 Apache Pulsar 流处理引擎 (SPE) 的关键设计组件。 为了保证零消息丢失，通常所说的“有效一次(至少一次)”，消息应用程序和/或 SPE 必须在故障重新处理数据之前的某个时间点重新连接到消息系统。 通过这种设计，Pulsar 支持零消息丢失和零消息重复。 除了在极少数情况下，Pulsar 纠正错误的速度非常快，以至于纠正后的消息仍会按时间顺序显示给用户。 Apache Kafka 并不是为完全减少数据丢失而设计的。 由于其设计，在某些故障条件下，消息可能会丢失。 在这里，我们再次看到 Pulsar 明显优于 Kafka。 这种技术进步应该不足为奇，因为 Pulsar 是为了纠正 Kafka 问题而有意发展的。

10 Apache Pulsar 获得了广泛支持

尽管 Apache Kafka 在发布时占据了先发优势，并且在工程界更为人所知，但最初的优势现在已经不那么重要了。

这种趋势变化的重要原因包括：

• 频繁发布 Pulsar 新版本——现在平均每季度发布一次。
• 目前选择 Pulsar 的主要企业包括：Capital One、Verizon、Splunk、Salesforce、OVH、腾讯和 Overstock。
• 非凡的媒体曝光，包括数百篇新文章、视频、培训平台、各大企业的白皮书、36 场会议、25+ 组织、600+ 注册，以及 Slack 官方频道的一系列日常活动，都在赞美 Apache Pulsar。
• Apache Pulsar 社区有 289 名贡献者，并且还在不断增加。