️阅读本文需 7 分钟
本系列文章将重点讨论 Pulsar 与 Kafka 的延迟性，之前的两篇文章已经介绍了测试方法（下图绿色部分）与测试细节（下图蓝色内容），可以点击下列标题直接查看：
本文将详细介绍 Pulsar 与 Kafka 的测试结果（下图红色内容）。Fsync 状态是实验中的一个变量，此外，为了更好地对比二者，测试者还调整了分区的数量。
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 个分区
讨论
由于在 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=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 有关的一切。
点击 链接 ，查看英文原稿