作为 Apache 软件基金会顶级项目,Apache Pulsar 是云原生时代消息队列和流融合系统,提供统一的消费模型,支持消息队列和流两种场景,既能为队列场景提供企业级读写服务质量和强一致性保障,又能为流场景提供高吞吐、低延迟。

得益于其存储计算分离的云原生架构设计,同时具备支持大集群、多租户、百万级 Topic、跨地域数据复制等企业级和金融级功能,Apache Pulsar 在越来越多行业和企业落地,如证券交易与金融科技、IoT 物联网、电商等行业,目前在腾讯、百度、滴滴、新浪微博、微信、中国银联、平安证券、华为云、金山云、BIGO 等国内外企业都有关键业务场景应用。

在行业内,Apache Pulsar 与 Apache Kafka 到底孰优孰劣话题的热度居高不下。大家通常会从二者的特性、能力、社区以及其他指标等多个角度进行对比。

2020 年,StreamNative 发布了 《​Pulsar 与 Kafka 基准测试报告​》,该报告纳入了更多性能指标,模拟实际场景,以求更准确地对比 Pulsar 和 Kafka。此后,Pulsar 社区和项目的发展始终处于加速之中。借助全球贡献者的努力,Pulsar 在近一年多的时间里迎来了诸多重大的性能改进。

性能比拼:2022 Apache Pulsar 与 Kafka 基准测试报告出炉_kafka

图 1:Pulsar 与 Kafka 的月度活跃贡献者对比

为了衡量这些改进的影响,由 Apache Pulsar 创始人之一、Apache Pulsar PMC 主席 Matteo Merli 领导的 StreamNative 工程师团队借助 Linux 基金会 Open Messaging 项目,使用 Apache Kafka 3.0.0 并使用 Confluent 在其 OpenMessaging 基准分支中推荐的配置,再次从吞吐量消息发送延迟方面对 Pulsar 和 Kafka 的性能进行了相同的测试。

本次基准测试选择了能代表消息领域流处理领域常见模式的几种测试场景,并对每个系统的极限展开测试。报告基于上述场景和结果对比 Apache Pulsar 与 Apache Kafka 的性能。

2022 版报告亮点解读

亮点一:最大吞吐量 PK - Pulsar 是 Kafka 的 2.5 倍

在单分区场景下,Pulsar 可以实现的最大吞吐量是 Kafka 的 2.5 倍(取决于是否启用 Journaling)。更高的吞吐量意味着更少的硬件与更低的运营成本。这对于如日志分析、网络安全和传感器数据收集等导入并处理大量数据的场景来说是一个巨大优势。

性能比拼:2022 Apache Pulsar 与 Kafka 基准测试报告出炉_hadoop_02

图 2:单分区的最大写入吞吐量 (MB/s):数值越高,代表性能越好。

Pulsar 与 Kafka 之间的吞吐量差异反映了这两个系统如何有效地将数据跨不同组件从生产者 “传输” 到 Broker,也反映了两个系统数据复制协议的不同。

Pulsar 在单分区上的吞吐量分别达到了 700 MB/s 和 580 MB/s,而 Kafka 在单分区上的吞吐量为 280 MB/s。这是因为 Pulsar 客户端库在发送消息到 Broker 之前会将多条消息合并成批量消息。然后 Broker 再将数据传输到存储节点。

在 Kafka 中,有两个因素妨碍了最大可达吞吐量:(1) 生产者默认限制为 5 个最大未完成批次;(2) Confluent 为实现高吞吐量而推荐的生产者缓冲区大小为 (batch.size=1048576) 。

注意:在 Kafka 中增加 batch.size 参数会对延迟产生负面影响。而 Pulsar 生产者则不然,其批处理延迟除了受批次最大大小影响,还受 batchingMaxDelay() 控制。

在 100 分区场景、同等持久性保证的情况下,Pulsar 在最大写入吞吐量方面能够胜过 Kafka。测试表明,在同等配置、同样流量的情况下,Pulsar 比 Kafka 减少 32% 的硬件需求。

性能比拼:2022 Apache Pulsar 与 Kafka 基准测试报告出炉_分布式_03

图 3: 100 分区的最大写入吞吐量 (MB/s): 数值越高,代表性能越好。

禁用 Journaling 情况下 Pulsar 取得了 1600(MB/s) 的吞吐量,Kafka 取得了 1087 (MB/s) 的吞吐量,而默认启用 Journaling 情况下 Pulsar 的吞吐量是 800 (MB/s) 。在同等持久性保证的情况下,Pulsar 在最大写入吞吐量方面能够胜过 Kafka。这个性能上的差异源于 Kafka 实现对磁盘的访问的方式。Kafka 将每个分区的数据存储在不同的目录和文件中,导致需要打开更多的文件用于写入,并将 IO 操作分散到各个磁盘。这增加了 Kafka 所依赖的操作系统 PageCache 的压力和争用。

读取文件时,操作系统尝试将数据块缓存到可用的系统 RAM 中。当数据在操作系统缓存中不可用时,则会从磁盘中读取数据并拉入缓存,此时线程会被阻塞。

将阻塞数据拉入缓存的代价是在为其他主题处理写入/读取请求时会产生显著的延迟 (约 100 毫秒)。在基准测试结果中,这种延迟表现为生产者的消息发送延迟。

在 Pulsar 的默认部署下 (启用 Journal 实现强持久性),吞吐量会低于 Kafka,因为虚拟机中两块可用磁盘中的一个会专用于 Journal。因此可用 IO 带宽被限制了。在生产环境中,可以通过增加磁盘来增加每个节点的 IOPS 性能,从而缓解这个限制。但在本基准测试中,我们则为每个系统使用相同的虚拟机资源配置。

亮点二:消息发送延迟 PK - Pulsar 比 Kafka 延迟低 100 倍

由于消息总线是底层技术栈组件,所以它需要提供稳定的低延迟,以保证应用程序提供自己的延迟 SLA。本报告测量了生产者在稳定状态下以固定速率发布时所感知到的延迟。

在消息系统常用场景中,有些应用要求数据必须能从生产应用程序有效且可靠地移动到消息系统以便持久化存储起来。在大容量或桌面用户不断的重试的前提下,低消息延迟使系统能够快速地将消息发布到消息总线。一旦消息发布成功,数据即能安全地进行各种“处理”。而延迟的增加会损害用户体验,将延迟性能稳定地保持在给定的 SLA (服务级别协议)之内是非常重要的。

在固定 500MB/s 的写入吞吐量情况下,Pulsar 在禁用 Journal 情况下提供 <1.6ms 的 99 百分位写入延迟,在启用 Journal 情况下则为 <8ms。在高百分位下,Pulsar 的延迟也仅轻微增加没有降级,而 Kafka 的延迟则快速飙升至 100 毫秒。

总而言之,Pulsar 提供稳定的消息发送延迟,比 Kafka 的 P99.99 (ms) 延迟低 100 倍。无论是否启用 Journaling,在以固定速率发布的情况下,在最大突发吞吐量以下、99.9% 及以上时,Pulsar 的延迟都比 Kafka 更低。

性能比拼:2022 Apache Pulsar 与 Kafka 基准测试报告出炉_java_04

图 4:500K 速率的消息发送延迟百分位 (毫秒):数值越低,代表性能越好

Pulsar 能做到更低延迟的原因在于:

  1. 1. 在禁用 Journaling 情况下运行 Pulsar 时,关键数据写入路径与磁盘访问是解耦的,因此不易受 IO 操作带来的干扰的影响。数据仅保证被复制到内存 (而操作系统 Page Cache 在高负载情况下会被阻塞),然后再被后台线程刷到磁盘。
  2. 2. Pulsar 在默认情况下启用 Journaling 情况下也能保持低延迟,这是因为 BookKeeper 复制协议能够忽略响应最慢的存储节点。由于内部磁盘垃圾收集机制,SSD 和 NVMe 磁盘的性能配置文件具有良好的平均写入延迟,但会有高达 100 毫秒的周期性的延迟峰值。BookKeeper 在使用 3/3/2 配置时能够平滑延迟,因为对每个 Entry 只需等待最快的两个存储节点响应即可。

相比之下,Kafka 复制协议要等待同步副本集合中的所有三个 Broker 返回。因此,除非 Broker 崩溃或者落后于 Leader 30 秒以上,否则 Kafka 中每个 Entry 都需要等待写入所有三个 Broker。

亮点三:追赶读 PK - Pulsar 历史读取速率比 Kafka 快 2.5 倍

对于数据库迁移/复制这类将数据传输/记录到 Pulsar 的场景来说,读取吞吐量至关重要。在历史数据读取过程中,Pulsar 的 I/O 隔离特性提供了稳定的低消息发送延迟,比 Kafka 低 2 个数量级。

Pulsar 的历史读取率是 Kafka 的 1.5 倍,Pulsar 消费者能够比 Kafka 消费者快约 2.5 倍耗尽 Backlog,而不会影响相关生产者的性能。因此使用 Pulsar 作为消息系统的应用可以在意外中断后只需一半的时间即可追上数据,在读取历史数据时实时数据流不受影响。

而在 Kafka 集群中消费者可能导致降级。这会影响 Kafka 集群的性能,并可能导致可靠性问题。

性能比拼:2022 Apache Pulsar 与 Kafka 基准测试报告出炉_hadoop_05

图 5a:追赶读的吞吐量 (msgs/s):数值越高,代表性能越好。

性能比拼:2022 Apache Pulsar 与 Kafka 基准测试报告出炉_kafka_06

图 5b:追赶读取时间 (秒):数值越短,代表性能越好。

性能比拼:2022 Apache Pulsar 与 Kafka 基准测试报告出炉_hadoop_07

图 5c:追赶读期间对消息发送延迟的影响 (毫秒):数值越低,代表越好。

这种延迟的增加是由于 Kafka 所使用的操作系统 Page Cache 的争用引起的。当 Backlog 大小超过 Kafka Broker 中的可用 RAM 时,操作系统会从缓存中逐出页面。这会导致 Page Cache 未命中,从而停止 Kafka 线程。当 Broker 中有足够多的生产者和消费者时,就会很容易陷入“缓存抖动”场景,时间就会花在从磁盘中缓存数据而很快又将其从缓存中逐出。

相比之下,Pulsar 底层的 BookKeeper 采用更巧妙的方式来执行写入和读取操作。Pulsar 并不依赖操作系统 Page Cache,因为 BookKeeper 有自己的一组写入和读取缓存,其逐出和预读都是专门为流式存储场景特别设计的。

关于团队和作者

StreamNative 是一家开源基础软件公司,由 Apache 软件基金会顶级项目 Apache Pulsar 创始团队组建而成,围绕 Pulsar 打造下一代云原生批流融合数据平台。StreamNative 作为 Apache Pulsar 商业化公司,专注于开源生态和社区构建,致力于前沿技术领域的创新,创始团队成员曾就职于 Yahoo、Twitter、EMC、Splunk 等知名大公司。

本报告作者

  • • Matteo Merli,Apache Pulsar PMC 主席,StreamNative CTO
  • • 李鹏辉,Apache Pulsar PMC 成员,StreamNative 首席架构师

下载完整版报告(PDF 文件)

限于文章篇幅,上述我们仅仅列举了在新版测评报告中的几点主要结论与发现、以及简要原因分析,在完整报告中还包含了本次测试使用的测试框架、测试配置以及用到的驱动文件和负载文件,感兴趣的开发者可利用提供的信息进行测试验证。

按下面方式获取《2022 Pulsar 与 Kafka 基准测试报告》完整版 PDF 文件(附 2020 版报告,合计约 100 页):

  1. 1. 转发如下海报到朋友圈
  2. 2. 截图朋友圈并私信 Bot
  3. 3. 填写下载表单,领取 PDF 文件