Apache|Apache Pulsar 与 Kafka 性能比较（延迟性（测试结果）） ApachePulsar与Kafka性能比较：延迟

?阅读本文需 7 分钟

本系列文章将重点讨论 Pulsar 与 Kafka 的延迟性，之前的两篇文章已经介绍了测试方法（下图绿色部分）与测试细节（下图蓝色内容），可以点击下列标题直接查看：

Apache Pulsar 与 Kafka 性能比较：延迟性（测试方法）
Apache Pulsar 与 Kafka 性能比较：延迟性（测试过程）

本文将详细介绍 Pulsar 与 Kafka 的测试结果（下图红色内容）。Fsync 状态是实验中的一个变量，此外，为了更好地对比二者，测试者还调整了分区的数量。

Apache|Apache Pulsar 与 Kafka 性能比较（延迟性（测试结果））

文章图片

Apache Pulsar 的测试结果本文将详细介绍 Apache Pulsar 延迟性的测试结果。我们会先介绍开启 fsync 的测试结果（Pulsar 默认的工作方式），再介绍关闭消息 flush 的测试结果。
对于每个工作负载，有两张图可供参考：一张图是测试期间发布延迟的 p99，另一张图是平均端到端延迟。另外，这两张图后附有在测试期间汇总延迟测量值并整理成的表格，提供延迟分布数据。
发布延迟的百分比计算比端到端延迟更准确，因为端到端延迟使用的是自动设置在消息头中的时间戳，并且该时间戳的精度为毫秒，而发布延迟的精度为纳秒。
所有测试均使用 100 字节的消息。在 15 分钟测试期间，仅使用两个客户端（生产与消费）服务器，且生产速率和消费速率恒定为每秒 5 万条消息。测试使用的 Apache Pulsar 版本为 2.4.0。
开启 fsync 时的延迟测试测试 1：1 个 topic，1 个分区

文章图片

文章图片

测试 2：1 个 topic，6 个分区

文章图片

文章图片

测试 3：1 个 topic，16 个分区
【Apache|Apache Pulsar 与 Kafka 性能比较（延迟性（测试结果））】

文章图片

文章图片

讨论
由于在 Pulsar 和 Kafka 中，分区都是并行单位，我们期待在分区数量增加时，延迟减小，实际测试结果也的确如此。总体而言，分区数量增加，发布延迟和端到端延迟都减小了。
每次测试中都有异常值，但是延迟最大值始终不超过 267 毫秒。发布延迟比端到端延迟数值波动更小。在所有测试中，发布延迟的 p9999 始终没有超过 11.6 毫秒。在 16 个分区的端到端延迟测试中，分区对延迟的影响最为明显。16 个分区测试的平均延迟（3 毫秒）是 1 个分区测试（9 毫秒）的三分之一。
Pulsar 的发布延迟不随时间而变化。所有测试运行时间均为 15 分钟。如图所示，测试期间平均发布延迟波动很小。端到端延迟随时间发生变化，在 90 秒内，平均延迟波动为 2 毫秒，并且延迟波动值几乎恒定。例如，端到端延迟的平均值为 1 个分区 9 毫秒，16 个分区 3 毫秒，但是变化值始终不超过 2 毫秒（9 毫秒增至 11 毫秒，3 毫秒变为 5 毫秒）。
关闭 fsync 时的延迟测试除了通过在 bookkeeper.conf 文件中设置 journalSyncData=https://www.it610.com/article/false，以禁用刷新每条消息到磁盘，并重启 Pulsar broker 和 BookKeeper 外，其他测试条件均相同。
测试 4：1 个 topic，1 个分区

文章图片

文章图片

测试 5 ：1 个 topic，6 个分区

文章图片

文章图片

测试 6：1 个 topic，16 个分区

文章图片

文章图片

讨论
和预想的一样，不启用 Flush 时，延迟减小，但不会减小太多。例如，1 个分区开启 Flush 时，p99 的发布延迟为 4.129 毫秒，而在不开启 Flush 时，发布延迟为 3.928 毫秒。在 16 个分区测试中，是否开启 Flush 对延迟几乎没有影响。在相同时间间隔内，端到端延迟周期性 2 毫秒的变化值和之前测试中一样（图中的波峰处）。
禁用 Flush 会损失一些持久性，因此在使用 Apache Pulsar 时，从延迟角度来看，禁用 Flush 并无益处。
Apache Kafka 的测试结果由于 Kafka 默认关闭 Flush，所以我们先进行此项测试。与 Pulsar 测试一样，所有测试都使用 100 字节的消息，消息速率为每秒 5 万条，仅使用两个客户端。在测试期间记录延迟，并整理成表格。测试使用的 Apache Kafka 版本为 2.11-2.3.0。
关闭 fsync 时的延迟测试测试 7：1 个 topic，1 个分区

文章图片

文章图片

测试 8：1 个 topic，6 个分区

文章图片

文章图片

测试 9：1 个 topic，16 个分区

文章图片

文章图片

讨论
首先看一下 1 个分区情况下的发布延迟，Kafka 对消息关闭 Flush 时，延迟小于 Pulsar（刷新时延迟为 2.969 毫秒，不刷新时延迟为 2.72 毫秒）。但是，在延迟分布中，可以看到 Pulsar 和 Kafka 的主要区别。
Pulsar 的延迟分布更集中，从 p50 到 p999，延迟从 2.916 毫秒增至 4.095 毫秒），而 Kafka 的延迟在 p999 达到 149.616 毫秒，结果相差很多。在 1 个分区的 p99，Pulsar 的延迟为 52.958 毫秒，而 Kafka 的延迟几乎是 Pulsar 延迟的 4 倍，为 201.701 毫秒。我们在比较默认模式下的不同，因此对 Pulsar 启用 Flush，Kafka 不启用 Flush。如果禁用 Pulsar 的磁盘 Flush，则 p999的延迟降为仅 4.508 毫秒。
观察 p99 的发布延迟就会发现，Kafka 测试中出现大量异常值的原因很明显。当发布延迟从个位数跃升至 100 毫秒以上时，Kafka 出现了周期性峰值。分区数量增加，发布延迟的变化减小，但仍然存在。将其与 Pulsar 进行比较就会发现，整个测试期间，p99 的发布延迟基本上是一条直线。
Pulsar 与 Kafka 之间的另一个不同点在于，分区数量增加，Pulsar 的发布延迟减小，而 Kafka 的发布延迟增大。虽然在 1 个分区测试中，Kafka 的平均发布延迟比 Pulsar 低，但在 6 个分区和 16 个分区测试中，Pulsar 的发布延迟更低。在 16 个分区测试中，Pulsar 的平均发布延迟小于 3 毫秒，而 Kafka 的平均发布延迟则约为 8.5 毫秒。
再看平均端到端延迟，1 个分区测试中，Kafka 的测试结果更好，但在分区数量增加时，端到端延迟与发布延迟相似，都随之增大。在 16 个分区测试中，Kafka 的平均端到端延迟为 11 毫秒，而 Pulsar 的平均值则接近 3 毫秒。在 Pulsar 测试中，可以观察到周期性 2 毫秒的峰值。在 Kafka 测试中，可以看到峰值更为频繁，且数值更高，通常在 5 毫秒以上
开启 fsync 时的延迟测试除了启用每条消息刷新（fsync），对测试中的每个 topic 进行配置（flush.messages=1, flush.ms=0），测试条件与之前完全相同。
测试 10：1 个 topic，1 个分区

文章图片

文章图片

测试 11：1 个 topic，6 个分区

文章图片

文章图片

测试 12：1 个 topic，16 个分区

文章图片

文章图片

讨论
Pulsar 的默认模式为启用 Flush，这组对比测试结果显示 Pulsar 表现更好。在 1 个分区测试中，不启用 Flush 时，Kafka 表现更好，当都设置为启用 Flush 时，Pulsar 的平均延迟为 2.969 毫秒，而 Kafka 的平均延迟则超出 Pulsar 的两倍，为 6.652 毫秒。
分区数量增加，Kafka 的延迟增大，在 16 个分区测试中，Pulsar 的延迟为 2.72 毫秒，而 Kafka 的延迟为 18.454 毫秒，超出 Pulsar 测试结果的 6 倍。
当配置 Kafka 为启用 Flush 时，仍然会出现较大的发布延迟峰值，不过发生频率不高。
在 Kafka 中，启用 Flush 会增加端到端延迟。Kafka 在 1 个分区中表现更好（7.129毫秒 vs 9.052 毫秒），而 Pulsar 在 6 个分区和 16 个分区中表现更好。随着时间的推移，Kafka 的端到端延迟会出现高达 5 毫秒的峰值。
总结基于以上测试结果，总结如下：

随着时间的推移，Pulsar 延迟的可预测性更高。与 Kafka 相比，Pulsar 延迟随时间变化的曲线更平滑。对比图表（6 个分区，平均端到端延迟，不刷新）显示，Kafka 的延迟低于 Pulsar，但是 Pulsar 的延迟值更为稳定。

文章图片

Pulsar 的延迟变化不大。Kafka 测试显示，大多数情况下，p999 延迟增加。而在 Pulsar 测试中，只有极少数情况下，延迟的 p999 会增加。对比图表（6 个分区，p99 的发布延迟，开启 fsync）显示，与 Kafka 相比，Pulsar 的延迟值更稳定：

文章图片

在使用单一 producer 和单一 consumer 时，Pulsar topic 分区数量增加，延迟减小；Kafka topic 分区数量增加，延迟增大。
在最高的要求消息要持久化的前提下（保证不丢消息），Pulsar 的延迟低于 Kafka。
关闭 fsync，Pulsar 会有更小的延迟，不能保证消息的持久性

对于延迟敏感工作负载而言，Pulsar 整体表现更好。Pulsar 可以保证一致的低延迟与强持久性。当然，并不是所有的工作负载都对延迟敏感。为提高吞吐量，可能需要承担延迟性更高的代价。
想要随时掌握 Pulsar 的研发进展、用户案例和热点话题吗？快来关注 Apache Pulsar 和 StreamNative 微信公众号，我们第一时间在这里分享与 Pulsar 有关的一切。