Apache Pulsar 与 Kafka 延迟性比较的测试过程是怎么样的

本篇文章为大家展示了Apache Pulsar 与 Kafka 延迟性比较的测试过程是怎么样的，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。

下面将介绍测试细节。

测试细节介绍：

>>> 设定基准

To set up the benchmark tests, we followed the steps documented on the OpenMessaging site. After applying the Terraform configuration, you get the following set of EC2 instances: 我们根据 OpenMessaging 网站上提供的步骤进行了基准测试。应用 Terraform 配置可以得到以下 EC2 实例集：

用于 Pulsar/BookKeeper 和 Kafka broker 的 i3.4xlarge 实例包含两个 NVMe SSD，以提高性能。这两个功能强大的虚拟机都有 16 个 vCPU、122 GiB 内存和高性能磁盘。

两个 SSD 对 Pulsar 而言是理想设定，因为不仅可以写入两个数据流，数据流还能在磁盘上并行。Kafka 还可以通过分配两个驱动器的分区来使用这两个 SDD。

用于 Pulsar 和 Kafka 的 Ansible playbook 使用 `tuned-adm` 命令（延迟性能配置文件）调优低延迟性能。

tuned-adm 命令详情参考 https://linux.die.net/man/1/tuned-adm

>>> 工作负载

虽然基准测试中附带了一些可以立即运行的工作负载，但是为了更接近 LinkedIn Engineering 博客中 Kafka 的测试结果，我们仍进行了一些修改。定义新工作负载并不难，只需创建带有测试更新参数的 YAML 文件即可。

阅读 LinkedIn 博客你便会发现，他们运行的消息大小都是 100 字节的，因为通常而言，如果消息太小（远小于100字节），测试对比结果并不明显；而所有的消息队列都不擅长处理“大消息”（远大于 100 字节），所以这里选择了一个折中的大小，即 100 字节，这也是所有消息系统测试中选择使用的单条消息的大小。

这个大小更有利于测试消息系统本身的性能。无论每条消息大小如何，用于测试的消息总量是固定的，消息系统处理消息的效率越高，性能越好；同时，网络或磁盘吞吐量限制对测试结果产生影响的可能性越低。消息系统在处理“大消息”时的性能表现也是一个值得探讨的话题，但我们目前只测试“小消息”。

另外，在测试中，我们还添加了 partition 数目为 6（简称：6 分区）的一项基准测试。因为在 LinkedIn 测试中使用了很多 6 分区，所以我们也把它添加进来。

LinkedIn 博客中包含 producer-only 和 consumer-only 工作负载，而我们在测试中使用的工作负载都同时包括 producer 和 consumer。原因有以下两点。

首先，就目前的情况来看，基准测试不支持 producer-only 或 consumer-only 工作负载；其次，在实际情况中，消息系统同时为 producer 和 consumer 服务。我们决定采用生产消息和消费消息的实际场景来测试。

综上所述，我们用于测试的负载集如下：

Kafka consumer group 和 Pulsar 订阅很相似，都允许一个或多个 consumer 接收一个 topic 上的所有消息。当一个 topic 与多个 consumer group/subscription 有关联时，消息系统向 topic 提供每条消息的多个副本，或“扇出“消息。

发布在 topic 上的每条消息都被发送到所有 consumer group/subscription。如果所有消息都被发送到同一 topic，且这一 topic 上只有一个 consumer group/subscription，则 producer 速率与 consumer 速率相等。

如果单个 topic 上有两个 consumer group/subscription，则 consumer 速率是 producer 速率的两倍。我们尽量简化测试，所以采用了前者，即多个 consumer 接收一个 topic 上的所有消息。

上述内容就是Apache Pulsar 与 Kafka 延迟性比较的测试过程是怎么样的，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注亿速云行业资讯频道。