Apache Kafka 的高性能始终广受青睐，它能在高速解决音讯的同时维持低提早。Apache Pulsar 在同类产品中倒退迅速，竞争力突出。
总有文章说 Pulsar 比 Kafka 性能更好，然而想找到测试的原始数据并不容易。另外，很多报告的测试数据并非来自最新版本的 Pulsar 和 Kafka，这两个我的项目都倒退得太快了，因而测试后果对新版本不具备代表性，所以咱们决定应用 Kafka（2.3.0）和 Pulsar（2.4.0），进行一系列性能测试，并将测试后果陆续公布进去。
本系列文章将重点探讨提早性，后续文章中会探讨吞吐量等。
音讯零碎性能测试
Kafka 和 Pulsar 软件包都蕴含性能测试工具。咱们能够批改任何一个性能测试工具，让它们彼此兼容。咱们将应用 OpenMessaging Project 的第三方基准框架。
可参考：http://openmessaging.cloud/
OpenMessaging Project 是一个 Linux Foundation Collaborative Project。OpenMessaging Project 的指标是为音讯和流技术提供厂商中立且实用于所有编程语言的规范。这一我的项目采纳了反对多种音讯技术的性能测试框架。
测试应用的代码都在 OpenMessaging GitHub 仓库中。
可参考：https://github.com/openmessag…
测试最后被设计为在私有云产品上运行，但咱们将在 Amazon Web Services（AWS）中应用规范 EC2 实例进行测试。
咱们将在 GitHub 上公布每个测试的残缺输入后果。欢送你剖析数据并提出见解，当然，你也能够本人测试，获取新数据。咱们发现，应用不同系列的 EC2 实例集进行测试，后果相近，因而你的测试后果也不会与咱们相差很多。
尽管应用 OpenMessaging 基准工具来运行的测试曾经蕴含了大量工作负载，然而为了让比照测试更乏味，咱们决定再加一些负载，这一想法来自 LinkedIn Engineering 网站上一篇名为「Benchmarking Apache Kafka: 2 Million Writes Per Second (On Three Cheap Machines）」的文章。
可参考：https://engineering.linkedin….
这是一篇很久以前的博客了，当初，硬件广泛更好，然而咱们并未应用顶配的测试设施。提前剧透：Kafka 和 Pulsar 都能够毫不费力地解决每秒 200 万次的写入，会在后续文章中详述。
OPENMESSAGING 基准测试
OpenMessaging 基准测试是一个开源的可扩大框架。只需增加 Terraform 配置、Ansible playbook 或能在测试工具中管制 producer 和 consumer 的 Java 库，就能够把音讯技术增加到测试中。目前，Kafka 和 Pulsar 中的 Terraform 配置是雷同的，在 AWS 中启动雷同的 EC2 实例集。
为了便于比拟，硬件配置应该雷同，因而，现有的基准代码简化了 Kafka 和 Pulsar 之间的比拟。
在理论测试开始前，我对所有测试进行了预测试。以恒定速率进行了提早测试，定期记录提早和吞吐量。
如果你想本人测试的话，须要留神以下几点：在 AWS 上运行测试费用很高；须要大量配置较好的 EC2 实例（对软件基准测试十分重要）；如需保障硬件不成为瓶颈，则需配置较好的硬件，而它的老本比拟高（每小时不低于 5 美元，一个月要 3800 美元）；在不进行测试时（例如，夜里），能够进行运行环境；确保在测试后删除所有资源。
性能注意事项
为了更好地了解测试后果，先介绍几个重要概念。首先，须要查看测试的目标：提早；而后，查看音讯的持久性，尤其是在将音讯存储到磁盘时；最初，须要理解 Kafka 和 Pulsar 中不同的音讯复制模型。
Kafka 和 Pulsar 之间有许多相似之处，但也有一些影响性能的显著差别。为了偏心地评估这两个零碎，须要理解以下差别：
对于提早测试
所有提早都必须蕴含应用程序和音讯零碎之间的网络提早。假如所有测试的网络配置雷同，并且网络产生的提早也雷同，那么网络提早对所有测试的影响是雷同的。在比拟提早时，雷同的网络提早很重要。
咱们指出这一点是因为测试后果与 LinkedIn Engineering 博客中的后果不雷同。假如博客文章过后的测试在专用的 1 GB 以太网上运行，而咱们的测试运行在私有云的实例上，网络带宽为 10 GB。所以，咱们的测试后果与那篇文章中的后果间接相比确有不妥。因为在测试中，网络配置是恒量，咱们能够比拟本次测试中 Kafka 和 Pulsar 音讯零碎之间的提早后果。
咱们记录了两种类型的提早：端到端提早和公布提早。
端到端提早
端到端提早绝对简略，指从 producer 发送音讯到 consumer 接管音讯的工夫。在实现 Pulsar 和 Kafka 的基准测试中，发送的工夫戳是由各自发送音讯的 API 主动生成的。当 consumer 接管到音讯时，生成第二个工夫戳。这两个工夫的差就是端到端提早。
端到端提早的简单之处在于用于测量工夫戳的时钟。在测量端到端提早时，必须同步工夫戳的时钟。如果没有同步，时钟之间的差别将会影响测量。最终测量后果实际上是时钟之间的差别，也就是音讯零碎的提早。因为时钟会随工夫漂移，所以在运行工夫长的测试中问题会更重大。
现实状况下，producer 和 consumer 在同一服务器上，应用同一时钟取得工夫戳，因而不存在提早。然而，基准测试的目标是将 producer 和 consumer 拆散到不同的服务器上，以调配负载。
另一个最佳计划是尽可能精确地同步服务器之间的时钟。AWS 提供收费的工夫同步服务（time sync service），该服务与 chrony 相结合，使 EC2 实例之间的时钟看起来非常靠近同步（误差在几微秒内）。在测试中，咱们顺便在所有客户端服务器上安装了 chrony，并配置应用 AWS 工夫源。
公布提早
公布提早指音讯从 producer 收回到 broker 的这段时间。音讯被 broker ack 后，则表明音讯被正确地发送到了 broker 且已被长久化。Procuder、broker、consumer 三者互相独立，当 producer 实现发送音讯操作之后（收到 ack 指令之后），这条音讯的胜利与否曾经和 producer 没有关系了。统一的低公布提早对 producer 来说是无益的，在 producer 筹备发送音讯时，broker 疾速接管音讯，容许 producer 持续解决 producer 级别的问题，例如，业务逻辑。这种音讯的发送是 broker 的要害个性。
在基准测试中，音讯采纳异步发送的模式，即 producer 不会阻塞音讯 ack 的操作。发送音讯的调用立刻返回，回调在音讯达到时进行确认。在异步发送中，公布提早看起来仿佛没那么重要，但其实不然。
Kafka: max.in.flight.requests.per.connection
Pulsar: maxPendingMessages
以上两者都有缓冲区，用来保留未确认的音讯。当缓冲区达到设定的阈值时，producer 开始阻塞（或进行，这由配置决定）。因而，如果音讯零碎没有疾速确认收到音讯，生产应用程序就会期待音讯零碎的操作。
在基准测试中，公布提早指从调用发送办法到触发确认回调的这段时间。这两个工夫戳都是在 producer 中生成的，因而无需思考时钟同步。
持久性与刷新音讯到磁盘
音讯零碎的持久性指在零碎呈现故障时，音讯不会失落。为了确保这一点，须要将音讯存储在平安的地位，即使运行音讯系统软件的服务器呈现故障，音讯也不会失落。Kafka 和 Pulsar 最终都向磁盘写入音讯，以提供持久性。
然而，只要求操作系统向文件系统写入音讯是不够的。向文件系统写入意味着将数据寄存在写入缓存，但不肯定平安地存储在磁盘上。因为缓存驻留在内存中，因而如果服务器解体（例如，断电、内核宕机），曾经写入缓存但还没有写入或刷新到磁盘的数据将会失落。强制将缓存数据写入磁盘的操作称为 fsync。为确保音讯曾经存储在磁盘上，须要触发 fsync 操作，在写入音讯后将文件缓存刷新到磁盘。
默认状况下，Kafka 不会显式地将每条音讯刷新到磁盘，它会在刷新操作系统时实现磁盘刷新。当服务器解体时，未刷新到磁盘的数据可能会失落。这一默认设置是出于性能思考的。写入磁盘比写入内存缓存慢，因而磁盘刷新使音讯解决性能降落。能够将 Kafka 配置为定期刷新（甚至能够设置为每条音讯写入后刷新），然而出于性能思考，不倡议这样做。
默认状况下，Pulsar 将每条音讯刷新到磁盘。音讯存入磁盘后才向 producer 确认，这在服务器解体时提供了更强的持久性保障。Pulsar 在保障持久性的同时，还能放弃高性能，是因为它应用 Apache BookKeeper 来存储音讯，而 BookKeeper 是专门为此优化的分布式日志存储系统。另外，在 Pulsar 中能够禁止 fsync 操作。
因为刷新磁盘会影响性能，咱们将对 Kafka 和 Pulsar 都进行两次测试，一次启用对每条音讯进行磁盘刷新，一次禁用。这有助于更好地比拟 Kafka 和 Pulsar。
音讯复制
Kafka 和 Pulsar 都通过多正本机制来确保音讯的高可用。即便失落了一个音讯正本，依然能够通过其余正本复原音讯。在 Kafka 和 Pulsar 中，音讯复制影响性能的形式不同。如何确认测试中 Kafka 和 Pulsar 之间的复制行为类似？
Kafka 应用 leader-follower 复制模型。Kafka 的一个 broker 被选为分区的 leader。首先将所有音讯写入 leader，follower 从 leader 中读取并复制音讯。Kafka 监控每个 follower 是否与 leader“同步”。应用 Kafka，能够在音讯胜利保留并被 producer 确认之前管制单个音讯的总正本数（复制因子）与须要同步的最小正本数（min.insync.replicas）。
典型的配置状况是，Kafka 保留音讯的 3 份正本，并且只会在至多 2 个正本（大多数）胜利写入后立即确认。这也是咱们在所有 Kafka 测试中采纳的配置（replication-factor=3，in.sync.replicas=2，acks=all）。
Pulsar 采纳 quorum-vote 复制模型。并行写入多个音讯正本。一旦确认已存储局部音讯正本，便会确认该音讯（ack quorum）。Leader-follower 模型通常向特定主题分区内的同一组 leader 和 follower 写入正本，而 Pulsar 能够将音讯正本平均摊派到不同的存储节点上，从而进步读写性能。
在测试中，为了确保测试的一致性，Pulsar 也采纳三正本的机制。Pulsar（配置：ensemble=3， write `quorum=3，ack quorum`=2）与 Kafka 的复制后果类似：3 个音讯正本，在失去其中任意两个正本的确认之后，立刻向 broker 返回音讯长久化胜利。
点击 链接，能够查看英文原稿。