对于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。以后已有泛滥国内外大型互联网和传统行业公司采纳 Apache Pulsar，案例散布在人工智能、金融、电信运营商、直播与短视频、物联网、批发与电子商务、在线教育等多个行业，如美国有线电视网络巨头 Comcast、Yahoo！、腾讯、中国电信、中国移动、BIGO、VIPKID 等。

Confluent 最近发展了一次基准测试，比照 Kafka、Pulsar 和 RabbitMQ 的吞吐量和提早差别。Confluent 博客显示，Kakfa 可能以“低提早”实现“最佳吞吐量”，而 RabbitMQ 可能以“较低的吞吐量”达到“低提早”。总体而言，基准测试结果显示 Kafka 在“速度”方面无疑更胜一筹。

Kafka 技术成熟欠缺，但当今泛滥公司（从跨国公司到创新型初创公司）还是首先抉择了 Pulsar。在近期举办的 Splunk 峰会 conf20 上，Splunk 公司首席产品官 Sendur Sellakumar 对外发表，他们决定用 Pulsar 取代 Kafka：

“… 咱们已把 Apache Pulsar 作为根底流。咱们把公司的前途压在了企业级多租户流的长期架构上。”

–Splunk 首席产品官 Sendur Sellakumar

很多公司都在应用 Pulsar，Splunk 只是其中一例。这些公司之所以抉择 Pulsar，是因为在古代弹性云环境（如 Kubernetes）中，Pulsar 可能以经济无效的形式横向扩大解决海量数据，不存在单点生效的问题。同时，Pulsar 具备诸多内置个性，诸如数据主动重均衡、多租户、跨地区复制和长久化分层存储等，不仅简化了运维，同时还让团队更容易专一于业务指标。

开发者们最终抉择 Pulsar 是因为 Pulsar 这些独特的性能和性能，让 Pulsar 成了流数据的基石。

理解了这些状况后，还需认真钻研 Confluent 的基准测试设置和论断。咱们发现有两个问题存在高度争议。其一，Confluent 对 Pulsar 的理解无限，这正是造成论断不精确的最大本源。如不理解 Pulsar，就不能用正确的衡量标准来测试 Pulsar 性能。

其二，Confluent 的性能测试基于一组狭隘的测试参数。这限度了后果的适用性，也无奈为读者提供不同工作负载和理论利用场景相匹配的精确后果。

为了向社区提供更精确的测试后果，咱们决定解决这些问题并反复测试。重要调整包含：

1. 咱们调整了基准测试设置，蕴含了 Pulsar 和 Kafka 反对的各持久性级别，在同一持久性级别下比照两者的吞吐量和提早。
2. 咱们修复了 OpenMessaging 基准测试（OMB）框架，打消因使用不同实例产生的变量，并纠正了 OMB Pulsar 驱动程序中的配置谬误。
3. 最初，咱们测量了其余性能因素和条件，例如分区的不同数量和蕴含 write、tailing-read 和 catch-up read 的混合工作负载，更全面地理解性能。

实现这些工作之后，咱们反复了测试。测试结果显示，对于更靠近实在工作负载的场景，Pulsar 的性能显著优于 Kafka，而对于 Confluent 在测试中所利用的根本场景，Pulsar 性能与 Kafka 性能相当。

以下各局部将重点阐明本次测试得出的最重要论断。在 StreamNative 基准测试后果章节，咱们具体介绍了测试设置和测试报告。

StreamNative 基准测试后果概要

1、在与 Kafka 的持久性保障雷同的状况下，Pulsar 可达到 605 MB/s 的公布和端到端吞吐量（与 Kafka 雷同）以及 3.5 GB/s 的 catch-up read 吞吐量（比 Kafka 高 3.5 倍）。Pulsar 的吞吐量不会因分区数量的减少和持久性级别的扭转而受到影响，而 Kafka 的吞吐量会因分区数量或持久性级别的扭转而受到重大影响。

2、在不同的测试实例（包含不同订阅数量、不同主题数量和不同持久性保障）中，Pulsar 的提早显著低于 Kafka。PulsarP99 提早在 5 到 15 毫秒之间。KafkaP99 提早可能长达数秒，并且会因主题数量、订阅数量和不同持久性保障而受到微小影响。

3、Pulsar 的 I/O 隔离显著优于 Kafka。在有消费者 catch up 读取历史数据时，PulsarP99 公布提早依然在 5 毫秒左右。相比之下，Kafka 的提早会因 catch up read 而受到重大影响。KafkaP99 公布提早可能会从几毫秒减少到几秒。

咱们所有的基准测试均 开源（Github 网址），感兴趣的读者能够自行生成后果，也可更深入研究该测试后果及仓库中提供的指标。

只管咱们的基准测试比 Confluent 的基准测试更精确全面，但并未涵盖全副场景。归根结底，通过本人的硬件 / 理论工作负载进行的测试，是任何一个基准测试都代替不了的。咱们也激励各位读者评估其余变量和场景，并利用本人的设置和环境进行测试。

深刻探索 Confluent 基准测试

Confluent 将 OpenMessaging 基准测试（OMB）框架 作为其基准测试的根据，并进行了一些批改。在本节中，咱们将阐明在 Confluent 基准测试中发现的问题，并论述这些问题如何影响 Confluent 测试后果的准确性。

Confluent 的设置问题

Confluent 基准测试论断不正确是因为 Pulsar 参数设置不合理。咱们会在 StreamNative 基准测试局部具体解说这些问题。除了 Pulsar 调优问题，Confluent 针对 Pulsar 和 Kafka 设置了不同的持久性保障。持久性级别会影响性能，两个零碎的持久性设置雷同，比照才具备参考价值。

Confluent 工程师对 Pulsar 采纳默认持久性保障，该保障比 Kafka 的持久性级别高。减少持久性级别会重大影响提早和吞吐量，所以 Confluent 测试对 Pulsar 提出了比 Kafka 更高的要求。Confluent 应用的 Pulsar 版本尚不反对将持久性升高到与 Kafka 雷同的级别，但 Pulsar 行将公布的版本反对该级别，在本次测试中也应用了该级别。如果 Confluent 工程师在两个零碎上应用的持久性设置雷同，那么测试结果显示的比照应该是精确的。咱们当然不会因 Confluent 工程师未应用尚未公布的性能而指摘他们。然而，测试记录并不能提供必要的情景，而且将其视为等同持久性设置的后果。本文会提供额定的情境阐明。

OMB 框架问题

Confluent 基准测试遵循 OMB 框架指南，该指南倡议在多个事件流零碎中应用同一实例类型。但在测试中，咱们发现同一类型的不同实例存在大量偏差，尤其是产生磁盘 I/O 故障的状况下。为了最大水平地缩小这种差别，咱们在每次运行 Pulsar 和 Kafka 时都应用了雷同实例，咱们发现这些实例在很大水平上改良了后果的准确性，磁盘 I/O 性能的渺小差别可能会对系统整体性能造成较大差别。咱们提议更新 OMB 框架指南，并在将来思考采纳这个倡议。

Confluent 钻研办法的问题

Confluent 基准测试仅测试了几种无限的场景。例如，理论工作负载包含写入、tailing read 和 catch-up read。当某一消费者正在读取日志“尾部”左近的最新消息时，即产生 tailing-read，Confluent 只测试了这一种场景。相比之下，catch-up read 在消费者有大量历史音讯时产生，必须耗费至“catch-up”地位到日志的尾部音讯，这是理论零碎中常见的要害工作。如果不思考 catch-up read，则会重大影响写入和 tailing read 的提早。因为 Confluent 基准测试只关注吞吐量和端到端提早，所以未能就各种工作负载下的预期行为提供全面后果。为了进一步让后果更靠近理论利用场景，咱们认为对不同数量的订阅和分区进行基准测试至关重要。很少有企业只关怀具备几个分区和消费者的大量主题，他们须要有能力包容具备不同主题 / 分区的大量不同消费者，以映射到业务用例中。

咱们在下表中概述了 Confluent 钻研办法的具体问题。

Confluent 基准测试的诸多问题源于对 Pulsar 的理解无限。为帮忙大家后续发展基准测试时防止这些问题，咱们和大家分享一些 Pulsar 技术见解。

为了发展精确的基准测试，需理解 Pulsar 的持久性保障。咱们将以此问题作为切入点进行探讨，先总体概述分布式系统的持久性，而后阐明 Pulsar 和 Kafka 在持久性保障上的差别。

分布式系统持久性概述

持久性是指在面对诸如硬件或操作系统故障等内部问题时，对系统一致性和可用性的维持能力。诸如 RDBMS 单节点存储系统依附 fsync 写入磁盘来确保最大的持久性。操作系统通常会缓存写入，在产生故障时，写入可能会失落，但 fsync 将确保将这些数据写入物理存储中。在分布式系统中，持久性通常来自数据复制，行将数据的多个正本散布到可独立生效的不同节点。但不应将本地持久性（fsync 数据）与复制持久性一概而论，两者目标不同。接下来咱们会解释这些个性的重要性及次要区别。

复制持久性和本地持久性

分布式系统通常同时具备复制持久性和本地持久性。各种类型的持久性由独自的机制管制。能够灵便组合应用这些机制，依据须要设置不同的持久性级别。

复制持久性通过一种算法创立数据的多个正本实现，所以同一数据可存储在多个地位，可用性和可拜访性均得以进步。正本的数量 N 决定了零碎的容错能力，很多零碎须要“仲裁”或 N/2 + 1 个节点来确认写入。在任何单个正本依然可用的状况下，一些零碎能够持续服务现有数据。这种复制机制对于解决彻底失落实例数据至关重要，新实例可从现有正本中从新复制数据，这对可用性和共识性也至关重要（本节不开展探讨该问题）。

相比之下，本地持久性决定了各个节点级别对确认的不同了解。本地持久性要求把数据 fsync 到长久存储，确保即便产生断电或硬件故障，也不会失落任何数据。数据的 fsync 可确保机器在短时间内呈现故障复原后，节点领有先前确认的全副数据。

持久性模式：同步和异步

不同类型的零碎提供不同级别的持久性保障。通常，零碎的整体持久性受以下因素影响：

• 零碎是否将数据 fsync 到本地磁盘
• 零碎是否将数据复制到多个地位
• 零碎何时确认复制到对等零碎
• 零碎何时确认写入客户端

在不同的零碎中，这些抉择差别很大，并非所有零碎都反对用户管制这些值。短少其中某些机制的零碎（例如非分布式系统中的复制），持久性更低。

咱们能够定义两种持久性模式，两者均可控制系统何时确认写入供外部复制，以及何时写入到客户端，即“同步”和“异步”。这两种模式操作如下。

• 同步持久性：仅在数据胜利 fsync 到本地磁盘（本地持久性）或复制到多个地位（复制持久性）后，零碎才向对等零碎 / 客户端返回写入响应。
• 异步持久性：在数据胜利 fsync 到本地磁盘（本地持久性）或复制到多个地位（复制持久性）前，零碎会向对等零碎 / 客户端返回写入响应。

持久性级别：测量持久性保障

持久性保障以多种形式存在，这取决于以下变量：

• 数据是否存储在本地，是否在多个地位复制或合乎这两种状况
• 何时确认写入（同步 / 异步）

与持久性模式一样，为辨别不同的分布式系统，咱们为持久性定义了四个级别。表 6 列出了从最高持久性到最低持久性的各个级别。

少数分布式关系数据库管理系统（例如 NewSQL 数据库）均可保障最高级别的持久性，所以将这类零碎归为 1 级。

与数据库一样，Pulsar 属于 1 级零碎，默认提供最高级别的持久性。此外，Pulsar 可针对每种利用别离自定义所需的持久性级别。相比之下，Kafka 大部分的生产环境部署都配置在 2 级或 4 级。据悉，通过设置 flush.messages=1 和 flush.ms=0，Kafka 也能达到 1 级规范。但这两项配置会重大影响吞吐量和提早，咱们会在基准测试中具体探讨这个问题。

上面咱们从 Pulsar 动手，具体探索各零碎的持久性。

Pulsar 的持久性

Pulsar 提供各级别的持久性保障，可将数据复制到多个地位，并将数据 fsync 到本地磁盘。Pulsar 领有两种持久性模式（即上文所述的同步和异步）。用户能够依据应用场景自定义设置，独自应用某一模式，或组合应用。

Pulsar 利用筏等效、基于仲裁的复制协定来管制复制的持久性。通过调整 ack-quorum-size 和 write-quorum-size 参数能够调整复制持久性模式。表 7 列出了这些参数的设置，表 8 列出了 Pulsar 反对的持久性级别。（Pulsar 复制协定和共识算法不属于本文探讨范畴，咱们会在后续的博客中深入探讨该畛域。）

Pulsar 通过向日志磁盘写入和（或）fsync 数据来管制本地持久性。Pulsar 还提供选项，通过表 9 中的配置参数来调整本地持久性模式。

Kafka 的持久性

Kafka 提供 3 种持久性级别：1 级，2 级（默认设置）和 4 级。Kafka 在 2 级提供复制持久性，在 4 级无奈提供持久性保障，因为不具备在确认写入之前将数据 fysnc 到磁盘的能力。通过设置 flush.messages=1 和 flush.ms=0，Kafka 能够达到 1 级零碎级别，但 Kafka 简直没有在生产环境部署过这种配置。

Kafka 的 ISR 复制协定管制复制持久性。通过调整与此协定关联的 acks 和 min.insync.replicas 参数，能够调整 Kafka 的复制持久性模式。表 10 列出了这些参数的设置。表 11 列出了 Kafka 反对的持久性级别。（无关 Kafka 复制协定的具体阐明不属于本文探讨范畴，咱们将在后续博客中深刻开掘 Kafka 协定和 Pulsar 协定的差别。）

与 Pulsar 不同，Kafka 不会将数据写入独自的日志磁盘。Kafka 会先确认写入操作，再将数据 fsync 到磁盘。这种操作可最大水平缩小写入和读取之间的 I/O 争用，并避免性能升高。

通过对每条音讯设置 flush.messages = 1 和 flush.ms = 0，Kafka 能够提供 fsync 性能，并且大大降低音讯失落的可能性，但这样会重大影响吞吐量和提早。因而，这种设置简直从未用于生产环境部署。

Kafka 无奈传输日志数据，如果遇到机器故障或断电，就有失落数据的危险。这个缺点很显著，影响很大，这也是腾讯计费零碎选用 Pulsar 的次要起因之一。

Pulsar 和 Kafka 在持久性方面的差别

Pulsar 的持久性设置灵便，用户可依据具体须要，优化持久性设置，满足各个应用程序、利用场景或硬件配置的要求。

Kafka 灵活性较差，依据场景限度，不能确保在两个零碎中的持久性设置雷同。这样就比拟难进行基准测试。为解决这一问题，OMB 框架倡议应用最靠近的可用设置。

理解了这些背景后，咱们来看看 Confluent 基准测试中的问题。Confluent 尝试模仿 Pulsar 的 fsync 行为，在他们的基准测试中，Confluent 为 Kafka 设置了异步持久性性能，为 Pulsar 设置了同步持久性性能。这种不对等导致测试后果不正确，作出的性能判断也有失偏颇。咱们的基准测试显示，Pulsar 与 Kafka 性能匹敌甚至超过 Kafka，同时 Pulsar 还提供更强的持久性保障。

StreamNative 基准测试

为了更精确理解 Pulsar 性能，咱们须要应用 Confluent 基准测试来解决这些问题。咱们将焦点放在调整 Pulsar 的配置上，确保两个零碎的持久性设置雷同，并纳入其余性能因素和条件，例如不同的分区数量和混合工作负载，从而测量不同利用场景下的性能。在上面的章节咱们会具体阐明咱们测试中的配置调整。

StreamNative 测试设置

咱们的基准测试设置囊括 Pulsar 和 Kafka 反对的全副持久性级别。这样，咱们才可对同一持久性级别下的吞吐量和提早进行比拟。咱们应用的持久性设置如下。

复制持久性设置

咱们的复制持久性设置与 Confluent 雷同，未做任何变动，为放弃完整性，此处沿用表 12 所列的设置。

Pulsar 新个性（新个性：）为应用程序提供了跳过日志记录的选项，从而放宽了本地持久性保障，防止了写入放大，进步了写入吞吐量。（该个性在下一版 Apache BookKeeper 提供）。咱们没有把它设置成默认个性，因为还是有可能失落音讯，所以并不倡议在大多数场景下应用。

为确保两种零碎性能比照精确，咱们在基准测试中应用了该个性。绕过 Pulsar 的日志记录可提供与 Kafka 默认 fsync 设置雷同的本地持久性保障。

Pulsar 的新个性包含本地持久性模式（Async – Bypass journal）。咱们利用此模式配置 Pulsar，放弃与 Kafka 本地持久性默认级别相匹配。表 13 列出了基准测试的具体设置。

StreamNative 框架

咱们在 Confluent OMB 框架分支 发现了一些问题，并修复了 OMB Pulsar 驱动程序中的一些配置谬误。咱们开发了新的基准测试代码（包含下述修复程序），都放在 开源 仓库中。

修复 OMB 框架问题

Confluent 遵循 OMB 框架倡议，利用两套实例— 一套用于 Kafka，一套用于 Pulsar。在咱们的基准测试中，咱们调配了一组三个实例来加强测试的可靠性。在首个测试中，咱们在 Pulsar 上运行了三个实例。而后利用同一组实例对 Kafka 进行同样的测试。

咱们应用同一台机器对不同零碎进行基准测试，在每次运行前都革除文件系统页面缓存，确保以后的测试不受到此前测试的影响。

修复 OMB Pulsar 驱动程序配置问题

咱们修复了 Confluent 的 OMB Pulsar 驱动程序配置中的许多谬误。以下各节将介绍咱们对 broker、bookie、生产者、消费者和 Pulsar image 所作的具体调整。

调整 Broker 配置

Pulsar broker 利用 managedLedgerNewEntriesCheckDelayInMillis 参数，确定 catch-up 订阅在向其消费者散发音讯前必须期待的时长（以毫秒为单位）。在 OMB 框架中，此参数的值设置为 10，这是 Confluent 基准测试论断不准的次要起因，Confluent 基准测试论断是 Pulsar 提早比 Kafka 高。咱们将该值更改为 0，模仿 Kafka 在 Pulsar 上的提早行为。更改后，所有测试场景中，Pulsar 的提早都显著低于 Kafka。

为了优化性能，咱们将 bookkeeperNumberOfChannelsPerBookie 参数值从 16 减少到 64，避免 broker 和 bookie 之间的任何单个 Netty 渠道成为瓶颈。当 Netty IO 队列中沉积大量音讯时，该瓶颈会导致高提早。

咱们将在 Pulsar 文档中提供更清晰的指南，帮忙用户优化端到端的提早。

调整 Bookie 配置

咱们为 Bookie 增加了新的配置，在绕过日志记录时测试 Pulsar 性能。Pulsar 和 Kafka 持久性保障半斤八两。

为测试该个性的性能，咱们基于 Pulsar 2.6.1 官网发行版构建了自定义镜像，涵盖了该调整。（详情查看 Pulsar Image。）

咱们手动配置了以下设置绕过 Pulsar 中的日志记录。

journalWriteData = false
journalSyncData = false

此外，咱们将 journalPageCacheFlushIntervalMSec 参数的值从 1 改成 1000，在 Pulsar 中对异步本地长久化进行基准测试（journalSyncData = false）。将该值调高后，Pulsar 可按如下所述模仿 Kafka 的刷写行为。

Kafka 通过将文件系统页面缓存刷写到磁盘来确保本地持久性。数据由一组称为 pdflush 的后盾线程刷写。能够设置 Pdflush，两次刷写之间的期待时长通常设置为 5 秒。将 Pulsar 的 journalPageCacheFlushIntervalMSec 参数设置为 1000，相当于 Kafka 上的 5 秒 pdflush 距离。更改后，咱们即可更准确地对异步本地持久性进行基准测试，并对 Pulsar 和 Kafka 进行更精确的比拟。

调整生产者配置

咱们的批处理配置与 Confluent 雷同，但有一个例外：即咱们减少了切换距离，使其比批处理距离更长。具体来说，咱们将 batchingPartitionSwitchFrequencyByPublishDelay 参数值从 1 更改为 2。这一更改确保 Pulsar 的生产者在每个批处理期间仅集中于一个分区。

将切换距离和批处理距离设置为雷同的值会导致 Pulsar 频繁切换分区，产生过多的小规模批处理，并可能影响吞吐量。把切换距离设置大于批处理距离，可最大水平升高这种危险。

调整消费者配置

当应用程序无奈疾速解决传入音讯时，Pulsar 客户端利用接管方队列施加反压。消费者接管方队列的规模会影响端到端提早。与规模较小的队列相比，规模较大的队列能够预取和缓存更多音讯。

这两项参数确定接管方队列的规模：receiverQueueSize 和 maxTotalReceiverQueueSizeAcrossPartitions。Pulsar 按下述形式计算接管方队列规模：

Math.min(receiverQueueSize, maxTotalReceiverQueueSizeAcrossPartitions / number of partitions)

例如，如果将 maxTotalReceiverQueueSizeAcrossPartitions 设置为 50000，当有 100 个分区时，Pulsar 客户端会在每个分区上将消费者的接管方队列规模设置为 500。

在咱们的基准测试中，maxTotalReceiverQueueSizeAcrossPartitions 从 50000 减少到 5000000。这种调优确保了消费者不会施加反压。

Pulsar image

咱们构建了自定义的 Pulsar 版本（v.2.6.1-sn-16），其中包含上文所述的 Pulsar 和 BookKeeper 修复。2.6.1-Sn-16 版本基于 Pulsar 2.6.1 官网发行版本，可从 https://github.com/streamnative/pulsar/releases/download/v2.6.1-sn-16/apache-pulsar-2.6.1-sn-16-bin.tar.gz  下载。

StreamNative 测试方法

咱们调整了 Confluent 基准测试的测试方法，通过理论工作负载全面理解性能。具体对测试作了如下调整：

1. 为评估以下内容，增加了 catch-up read

• 解决 catch-up read 时，每个零碎可达到的最大吞吐量
• 写入如何影响公布和端到端提早

2. 更改分区数量，查看每个更改如何影响吞吐量和提早
3. 更改订阅数量，查看每个更改如何影响吞吐量和提早

咱们的基准测试场景测试了下述各类工作负载：

• 最大吞吐量 ：各零碎可达到的最大吞吐量？
• 公布与 Tailing Read 提早 ：各零碎在给定的吞吐量下可达到的最低公布和端到端迁延提早？
• Catch-up read：从大量待办事项中读取音讯时，各零碎可实现的最大吞吐量？
• 混合工作负载 ：消费者执行 catch-up 操作时，每个零碎能够实现的最低公布和端到端迁延提早级别是多少？Catch-up read 如何影响公布提早和端到端迁延提早？

Testbed

OMB 框架倡议，对于实例类型和 JVM 配置，应用特定的 testbed 定义；对于生产者、消费者和服务器端，应用工作负载驱动程序配置。咱们的基准测试应用了与 Confluent 雷同的 testbed 定义。对于这些 testbed 定义，可查看 Confluent OMB 仓库中 StreamNative 分支。

上面将重点介绍咱们所察看到的磁盘吞吐量和磁盘 fsync 提早。要解释基准测试后果，必须思考这些硬件指标。

磁盘吞吐量

咱们的基准测试采纳与 Confluent 雷同的实例类型，具体为 i3en.2xlarge（带 8 个 vCore，64 GB RAM，2 x 2、500 GB NVMe SSD）。咱们确认 i3en.2xlarge 实例可反对两个磁盘间高达 655 MB/s 的写入的吞吐量。请参阅下文 dd 后果。

Disk 1
dd if=/dev/zero of=/mnt/data-1/test bs=1M count=65536 oflag=direct
65536+0 records in
65536+0 records out
68719476736 bytes (69 GB) copied, 210.08 s, 327 MB/s
Disk 2
dd if=/dev/zero of=/mnt/data-2/test bs=1M count=65536 oflag=direct
65536+0 records in
65536+0 records out
68719476736 bytes (69 GB) copied, 209.635 s, 328 MB/s

磁盘数据同步提早

在进行提早相干测试时，重要的是捕捉 NVMe SSD 上的 fsync 提早。咱们察看到，这 3 个实例的 P99 fsync 提早在 1 毫秒到 6 毫秒之间，如下图所示。如前所述，不同状况下磁盘产生很大差别，次要体现在该提早中，咱们发现有一组实例提早统一。

StreamNative 基准测试后果

下文将总结咱们的基准测试后果。如需查看残缺的基准测试报告，能够在 StreamNative 官网下载 或者在 openmessaging-benchmark 仓库查看。

最大吞吐量测试

最大吞吐量测试旨在确定在解决不同持久性保障的工作负载（包含公布和 tailing-read）时，各零碎可实现的最大吞吐量。咱们更改了主题分区的数量，查看每个更改如何影响最大吞吐量。

咱们发现：

1. 将持久性保障（同步复制持久性，同步本地持久性）配置为 1 级时，Pulsar 的最大吞吐量约为 300 Mb/s，这是日志磁盘带宽的物理极限。有 100 个分区时，Kafka 可达到 420 MB/s 左右。值得注意的是，在持久性为 1 级时，Pulsar 配置为一个磁盘用作日志磁盘进行写入，另一个磁盘用作 ledger 磁盘进行读取；而 Kafka 同时应用两个磁盘进行读取和写入。只管 Pulsar 的设置可能提供更好的 I/O 隔离，但其吞吐量也受单个磁盘最大带宽（〜300 MB/s）的限度。为 Pulsar 配置备用磁盘，可能实现更具老本效益的运行。此议题会在后续博客中探讨。
2. 当将持久性（同步复制持久性和异步本地持久性）配置为 2 级时，Pulsar 和 Kafka 均可达到约 600 MB/s 的最大吞吐量。两个零碎都达到了磁盘带宽的物理极限。
3. Kafka 在一个分区上的最大吞吐量仅为 Pulsar 最大吞吐量的二分之一。
4. Pulsar 的吞吐量不会因更改分区数量而受到影响，但 Kafka 的吞吐量会受到影响。

• 当分区数量从 100 减少到 2000 时，Pulsar 放弃了最大吞吐量（在 1 级持久性保障下约为 300 MB/s，在 2 级持久性保障下约为 600 MB/s）。
• 当分区数量从 100 个减少到 2000 个时，Kafka 的吞吐量降落一半。

公布和端到端提早测试

公布和端到端提早测试旨在确定在解决不同持久性保障的工作负载（包含公布和 tailing-read）时，各零碎可实现的最低提早。咱们批改了订阅数量和分区数量，以理解每个更改如何影响公布和端到端提早。

咱们发现：

1. 在所有测试用例中，Pulsar 的公布和端到端提早都显著（数百倍）低于 Kafka，这评估出了各种持久性保障以及不同数量的分区和订阅。即便分区数量从 100 减少到 10000 或订阅数量从 1 减少到 10，Pulsar P99 公布提早和端到端提早都在 10 毫秒之内。
2. 订阅数量和分区数量变动会对 Kafka 的公布和端到端提早产生微小影响。

• 当订阅数量从 1 减少到 10 时，公布和端到端提早均从约 5 毫秒减少到约为 13 秒。
• 当主题分区数量从 100 减少到 10000 时，公布和端到端提早都从约 5 毫秒减少到约 200 秒。

Catch-up read 测试

Catch-up read 测试旨在确定在解决仅蕴含 catch-up read 的工作负载时各零碎可实现的最大吞吐量。测试开始时，生产者以每秒 200K 的固定速率发送音讯。生产者发送了 512GB 数据后，消费者开始读取收到的音讯。消费者解决了累积音讯，当生产者持续以雷同速度发送新音讯时，消费者能够和生产者放弃同步。

解决 catch-up read 时，Pulsar 的最大吞吐量比 Kafka 快 3.5 倍。Pulsar 的最大吞吐量为 3.5 GB/s（350 万条音讯 / 秒），而 Kafka 的吞吐量仅为 1 GB/s（100 万条音讯 / 秒）。

混合工作负载测试

混合工作负载测试旨在确定 catch-up read 对混合工作负载中的公布和 tailing read 的影响。在测试开始时，生产者以每秒 200K 的固定速率发送音讯，而消费者以 tailing 模式生产音讯。生产者产生 512GB 音讯后，将启动一组新的 catch-up 消费者，从头开始读取所有音讯。同时，生产者和现有的 tailing-read 消费者持续以雷同的速度公布和应用音讯。

咱们应用不同的持久性设置对 Kafka 和 Pulsar 进行了测试，发现 catch-up read 会重大影响 Kafka 的公布提早，但对 Pulsar 的影响很小。Kafka P99 公布提早从 5 毫秒减少到 1-3 秒，而 Pulsar P99 公布提早放弃在几毫秒到数十毫秒之间。

论断

基准测试通常仅出现业务逻辑和配置选项的狭隘组合，可能反映或不反映理论利用场景或最佳实际，这是基准测试比拟辣手的局部。基准测试可能会因其框架、设置和钻研办法的问题而有失偏颇。咱们在 Confluent 最近的基准测试中发现了这些问题。

应社区要求，StreamNative 团队着手发展该基准测试，从而就 Pulsar 的真实性能提供见解和认识。为了使基准测试更加精确，咱们修复了 Confluent 基准测试中存在的问题，同时增加了新的测试参数，帮忙咱们深刻探索各技术在实在用例中的比照后果。

依据咱们的基准测试后果，在同一持久性保障下，在相似实在利用场景的工作负载中，Pulsar 性能超过 Kafka；在 Confluent 利用的同样无限测试用例中，Pulsar 可达到与 Kafka 雷同的端到端吞吐量。此外，在每个不同的测试实例（包含不同的订阅数量、主题数量和持久性保障）中，Pulsar 的提早优于 Kafka，并且 I/O 隔离也比 Kafka 更好。

如前所述，任何一个基准测试均不能代替各自硬件上按实在工作负载所做的测试。咱们激励读者应用本人的设置和工作负载来测试 Pulsar 和 Kafka，以理解每个零碎在特定生产环境中的性能。如果你对 Pulsar 最佳实际有任何疑难，请间接 分割咱们 或随时退出 Pulsar Slack。

将来几个月，咱们会公布一系列博客，帮忙社区更好地了解并利用 Pulsar 满足各自业务需要。咱们会介绍 Pulsar 在不同工作负载和设置中的性能，介绍如何在不同的云提供商和本地环境中抉择和调整硬件大小，以及如何利用 Pulsar 构建最具老本效益的流数据平台。

作者简介：

郭斯杰 ，StreamNative 联结创始人兼 CEO。郭斯杰从事音讯和流数据行业十多年，是音讯和流数据资深专家。在创建 StreamNative 前，他联结开办过 Streamlio 公司，专一实时解决方案。他曾任 Twitter 音讯基建团队技术负责人，联结创立了 DistributedLog 和 Twitter EventBus。在雅虎任职期间，他率领团队开发了 BookKeeper 和 Pulsar。他是 Apache BookKeeper 副总裁和 Apache Pulsar PMC 成员。

李鹏辉 ，StreamNative 软件工程师，Apache Pulsar Committer/PMC 成员。李鹏辉曾任职智联招聘，期间他作为次要推动者将 Apache Pulsar 落地智联招聘。他的工作经验始终围绕音讯零碎和微服务，目前已全力投入到 Pulsar 的世界中。

参考链接:

• StreamNative 基准测试报告
• StreamNative 基准测试 Github 地址
• Pulsar image 下载地址
• OpenMessaging 基准测试（OMB）框架
• 腾讯计费零碎为何抉择应用 Pulsar

相干浏览

• Pulsar 与 Kafka 全方位比照（上篇）：性能、性能、用例
• Pulsar 与 Kafka 全方位比照（下篇）：案例、个性、社区
• Apache Pulsar 与 Apache Kafka 在金融场景下的性能比照剖析

点击 链接，下载英文版文件