此外，对于所比较的三个系统，为了获得更好的延迟性能，我们使用 tune -adm 的延迟性能配置文件对操作系统进行了调优，它会禁用磁盘和网络调度器的任何动态调优机制，并使用性能调控器进行 CPU 频率调优。它将每个内核的 p-state 固定在可能的最高频率上，并将 I/O 调度器设置为 deadline，从而提供一个可预测的磁盘请求延迟上限。最后，它还优化内核中的电源管理服务质量（QoS），这是为了提高性能，而不是省电。

内存

与 OMB 中的默认实例相比，i3en.2xlarge测试实例物理内存几乎是前者的一半（64 GB vs. 122 GB）。优化 Kafka 和 RabbitMQ 使其与测试实例兼容非常简单。两者都主要依赖于操作系统的页面缓存，随着新实例的出现，页面缓存会自动缩小。

然而，Pulsar 代理以及 BookKeeper bookie 都依赖于堆外 / 直接内存缓存，为了使这两个独立进程可以在i3en.2xlarge实例上良好地运行，我们调整了 JVM 堆 / 最大直接内存大小。具体来说，我们将堆大小从每个 24 GB（原始的 OMB 配置）减半为每个 12 GB，在两个进程和操作系统之间按比例划分了可用物理内存。

在测试中，当目标吞吐量比较高时，我们遇到了java.lang.OutOfMemoryError: Direct buffer memory错误，如果堆大小再低一点，就会导致 bookie 完全崩溃。这是使用堆外内存的系统所面临的典型的内存调优问题。虽然直接字节缓冲区是避免 Java GC 的一个有吸引力的选项，但是大规模使用是一个颇具挑战性的做法。

5、吞吐量测试

我们开始测量的第一件事是，在网络、磁盘、CPU 和内存资源数量相同的情况下，每个系统可以实现的峰值稳定吞吐量。我们将稳定峰值吞吐量定义为消费者在不增加积压的情况下可以跟得上的最高平均生产者吞吐量。

fsync 的效果

如前所述，Apache Kafka 的默认建议配置是使用底层操作系统指定的页面缓存刷新策略（而不是同步地 fsync 每个消息）flush/fsync 到磁盘，并依赖复制来实现持久性。从根本上说，这提供了一种简单而有效的方法来分摊 Kafka 生产者所使用的不同批次大小的成本，在各种情况下都可以实现最大可能的吞吐量。如果 Kafka 被配置为每次写时 fsync，那么我们就会因强制进行 fsync 系统调用而人为地妨碍了性能，并且没有获得任何额外的好处。

也就是说，考虑到我们将要讨论这两种情况的结果，我们仍然有必要了解在 Kafka 中每次写时 fsync 的影响。各种生产者批次大小对 Kafka 吞吐量的影响如下所示。吞吐量随着批次大小的增加而增加，直到到达“最佳点”，即批次大小足以让底层磁盘完全饱和。在批次大小较大时，将 Kafka 上的每条消息 fsync 到磁盘（图 2 中的橙色条）可以产生类似的结果。注意，这些结果仅在所述实验平台的 SSD 上得到了验证。Kafka 确实在所有批次大小上都充分利用了底层磁盘，在批次大小较小时最大化 IOPS，在批次大小较大时最大化磁盘吞吐量，甚至在强制 fsync 每条消息时也是如此。

图 2：批次大小对 Kafka 吞吐量（每秒消息数）的影响，绿条表示 fsync=off（默认），橙条表示 fsync 每条消息

从上图可以明显看出，使用默认的 fsync 设置（绿条）可以让 Kafka 代理更好地管理 page flush，从而提供更好的总体吞吐量。特别是，在生产者批次大小较小（1 KB 和 10 KB）时，使用默认同步设置的吞吐量比 fsync 每条消息的吞吐量高 3 到 5 倍。然而，批次较大（100 KB 和 1 MB）时，fsync 的成本被均摊了，吞吐量与默认 fsync 设置相当。

Pulsar 在生产者上实现了类似的批次，并在 bookie 间对产生的消息进行 quoro 风格的复制。BookKeeper bookie 在应用程序级实现分组提交 / 同步到磁盘，以最大化磁盘吞吐量。在默认情况下（由 bookie 配置journalSyncData=true控制），BookKeeper 会将写入 fsync 到磁盘。

为了覆盖所有的情况，我们测试 Pulsar 时在 BookKeeper 上设置了journalSyncData=false，并与 Kafka 的默认（建议）设置（不对每条消息进行 fsync）进行了比较。但是，我们在 BookKeeper bookie 上遇到了大量延迟和不稳定性，表明存在与 flush 相关的队列等待。我们还用 Pulsar 提供的工具pulsar-perf验证到了同样的行为。据我们所知，在咨询了 Pulsar 社区后，这似乎是一个 Bug，所以我们选择从我们的测试中排除它。尽管如此，考虑到我们可以看到磁盘在journalSyncData=true时吞吐量达到最大，我们相信它无论如何都不会影响最终结果。

图 3：Pulsar 在 BookKeeper 设置了journalSyncData=true时，吞吐量明显下降，并且出现了延迟峰值

图 4：BookKeeper journal 回调队列在journalSyncData=false设置下的增长情况

当且仅当消息尚未被消费时，RabbitMQ 会使用一个持久队列将消息持久化到磁盘。然而，与 Kafka 和 Pulsar 不同，RabbitMQ 不支持“回放”队列来再次读取较旧的消息。从持久性的角度来看，在我们的基准测试中，消费者与生产者保持同步，因此，我们没有注意到任何写入磁盘的操作。我们还在一个三代理集群中使用了镜像队列，使 RabbitMQ 提供与 Kafka 和 Pulsar 相同的可用性保证。

测试设置

本实验按照以下原则和预期保证进行设计：

• 为了实现容错，消息复制 3 份（具体配置见下文）；

• 为了优化吞吐量，我们启用了所有三个系统的批处理。我们的批处理是 1MB 数据最多 10 毫秒；

• 为 Pulsar 和 Kafka 的一个主题配置了 100 个分区；

• RabbitMQ 不支持主题分区。为了匹配 Kafka 和 Pulsar 的设置，我们声明了一个 direct exchange（相当于主题）和链接队列（相当于分区）。关于这个设置的更多细节见下文。

OMB 使用一个自动速率发现算法。该算法通过以多个速率探测积压来动态地获取目标生产者的吞吐量。在许多情况下，我们看到速率在每秒 2 条消息到每秒 50 万条消息之间剧烈波动。这严重影响了实验的可重复性和准确性。在我们的实验中，我们没有使用该特性，而是显式地配置了目标吞吐量，并按每秒 10K、50K、100K、200K、500K 和 100 万条生产者消息的顺序稳步提高目标吞吐量，四个生产者和四个消费者都使用 1 KB 的消息。然后，我们观察了每个系统在不同配置下提供稳定端到端性能的最大速率。

吞吐量结果

我们发现，Kafka 在我们所比较的系统中吞吐量最高。考虑到它的设计，产生的每个字节都只在一个编码路径上写入磁盘一次，而这个编码路径已经被世界各地的数千个组织优化了近十年。我们将在下面更详细地研究每个系统的这些结果。

图 5：比较这三个系统的峰值稳定吞吐量：100 个主题分区，1 KB 消息，使用 4 个生产者和 4 个消费者

我们将 Kafka 配置为batch.size=1MB和linger.ms=10，以便生产者可以有效地对发送给代理的写操作进行批处理。此外，我们在生产者中配置了acks=all和min.insync.replicas=2，确保在向生产者返回确认之前每条消息至少复制到两个代理。我们发现，Kafka 能够有效地最大限度地使用每个代理上的磁盘——这是存储系统的理想结果。

图 6：使用默认推荐 fsync 设置的 Kafka 性能。该图显示了 Kafka 代理上的 I/O 利用率和相应的生产者 / 消费者吞吐量（来源：Prometheus 节点指标）。

我们还采用另一种配置对 Kafka 进行了基准测试，即在确认写操作之前使用flush.messages=1和flush.ms=0在所有副本上将每条消息 fsync 到磁盘。结果如下图所示，非常接近默认配置。

图 7：Prometheus 节点指标显示 Kafka 代理上的 I/O 利用率以及相应的生产者 / 消费者吞吐量。

在生产请求排队方面，Pulsar 的生产者与 Kafka 的工作方式不同。具体来说，它内部有每个分区的生产者队列，以及对这些队列的大小限制，对来自给定生产者的所有分区的消息数量设置了上限。为了避免 Pulsar 生产者在发送消息的数量上遇到瓶颈，我们将每个分区和全局限制均设置为无穷大，同时匹配基于 1 MB 字节的批处理限制。

.batchingMaxBytes(1048576) // 1MB.batchingMaxMessages(Integer.MAX_VALUE).maxPendingMessagesAcrossPartitions(Integer.MAX_VALUE);

我们还为 Pulsar 提供了更高的基于时间的批处理限制，即batchingMaxPublishDelayMs=50，以确保批处理主要是由字节限制引起的。我们通过不断增加这个值，直到它对 Pulsar 最终达到的峰值稳定吞吐量没有可测量的影响。对于复制配置，我们使用了ensemble blesize =3、writeQuorum=3、ackQuorum=2，这与 Kafka 的配置方式相当。在 BookKeeper 的设计中，bookie 将数据写入 journal 和 ledger 中，我们注意到，峰值稳定吞吐量实际上是 Kafka 所能达到的吞吐量的一半。我们发现，这种基本的设计选择对吞吐量有深远的负面影响，直接影响了开销。一旦 BookKeeper bookie 的 journal 磁盘完全饱和，Pulsar 的生产者速率就会被限制在那个点上。

图 8：Prometheus 节点指标显示了 BookKeeper journal 磁盘达到极限和最终在 BookKeeper bookie 上测得的吞吐量。

为了进一步验证这一点，我们还配置 BookKeeper 在 RAID 0 配置 中使用两个磁盘，这为 BookKeeper 提供了将 journal 和 ledger 写操作分到两个磁盘上的机会。我们观察到，Pulsar 最大限度地利用了磁盘的联合吞吐量（~650 MB/s），但峰值稳定吞吐量仍然限制在 ~340 MB/s。

图 9：Prometheus 节点指标显示，BookKeeper journal 磁盘在 RAID 0 配置下仍然达到极限

图 10：Prometheus 节点指标显示，RAID 0 磁盘已达到极限，以及最终在 Pulsar 代理上测得的吞吐量。

Pulsar 有一个分层架构，将 BookKeeper bookie（存储）与 Pulsar 代理（存储的缓存 / 代理）分开。出于完整性考虑，我们也在分层部署中运行了上述吞吐量测试，将 Pulsar 代理移到了另外三个计算优化的c5n.2xlarge实例上（8 vCores， 21 GB RAM， Upto 25 Gbps network transfer， EBS-backed storage）。BookKeeper 节点仍在存储优化的i3en.2xlarge实例上。这使得在这个特殊的设置中，Pulsar 和 BookKeeper 总共有 6 个实例 / 资源，比 Kafka 和 RabbitMQ 多了 2 倍 的 CPU 资源和 33% 的内存。

即使在高吞吐量下，系统也主要受到 I/O 限制，而且我们没有发现这种设置带来任何提升。该特定运行的完整结果见下表。事实上，Pulsar 的两层架构似乎只是增加了开销——两个 JVM 占用了更多的内存、两倍的网络传输以及系统架构中更多的移动部件。我们预计，当网络受到限制时（不像我们的测试提供了过剩的网络带宽），Pulsar 的两层架构将以两倍的速度耗尽网络资源，进而降低性能。

与 Kafka 和 Pulsar 不同的是，RabbitMQ 在主题中没有分区的概念。相反，RabbitMQ 使用 exchange 将消息路由到链接队列，使用头属性（header exchange）、路由键（direct 和 topic exchange）或绑定（fanout exchange），消费者可以从中处理消息。为了匹配工作负载的设置，我们声明了一个 direct exchange（相当于主题）和链接队列（相当于分区），每个队列专用于为特定的路由键提供服务。端到端，我们让所有生产者用所有路由键（轮询）生成消息，让消费者专门负责每个队列。我们还按照社区建议的最佳实践 优化了 RabbitMQ：

• 启用复制（将队列复制到集群中的所有节点）

• 禁用消息持久化（队列仅在内存中）

• 启用消费者自动应答

• 跨代理的负载均衡队列

• 24 个队列，因为在 RabbitMQ 中，每个队列使用一个专用的内核（8 个 vCPUx 3 个代理）

RabbitMQ 在复制开销方面表现不佳，这严重降低了系统的吞吐量。我们注意到，在此工作负载期间，所有节点都是 CPU 密集型的（见下图右侧 y 轴绿线），几乎没有留出任何余地来代理任何其他消息。

图 11：RabbitMQ 吞吐量 + CPU 使用率。

6、延迟测试

考虑到流处理和事件驱动架构的日益流行，消息系统的另一个关键方面是消息从生产者穿过管道通过系统到达消费者的端到端延迟。我们设计了一个实验，在每个系统都维持在最高稳定吞吐量而又没有显示出任何资源过度使用迹象的情况下，对所有三个系统进行比较。

为了优化延迟，我们更改了所有系统的生产者配置，将消息批处理时间设为最多仅为 1 毫秒（在吞吐量测试中是 10 毫秒），并让每个系统保持默认推荐配置，同时确保高可用性。Kafka 被配置为使用其默认的 fsync 设置（即 fsync off）， RabbitMQ 被配置为不持久化消但镜像队列。在反复运行的基础上，我们选择在速率 200K 消息 / 秒或 200MB/s 下对比 Kafka 和 Pulsar，低于这个测试平台上单磁盘 300MB/s 的吞吐量限制。我们观察到，当吞吐量超过 30K 消息 / 秒时，RabbitMQ 将面临 CPU 瓶颈。

延迟结果

图 12：在 200K 消息 / 秒（Kafka 和 Pulsar，消息大小 1KB）和 30K 消息 / 秒（RabbitMQ，它不能承受更高的负载）速率下测得的配置为高可用标准模式的端到端延迟。注：延迟（毫秒）越低越好。

Kafka 的延迟始终比 Pulsar 更低。在这三个系统中，RabbitMQ 实现了最低的延迟，但考虑到其有限的垂直可扩展性，只是在吞吐量低很多的情况下才能提供。由于实验的设置是有意的，所以对于每个系统，消费者总是能够跟上生产者的速度，因此，几乎所有的读取都是从所有三个系统的缓存 / 内存中。

Kafka 的大部分性能可以归因于做了大量优化的消费者读取实现，它建立在高效的数据组织之上，没有任何额外的开销，比如数据跳过。Kafka 充分利用了 Linux 页面缓存和零复制机制来避免将数据复制到用户空间中。通常，许多系统（如数据库）都构建了应用程序级缓存，为支持随机读 / 写工作负载提供了更大的灵活性。无论如何，对于消息系统，依赖页面缓存是一个很好的选择，因为典型的工作负载执行顺序读 / 写操作。Linux 内核经过多年的优化，能够更智能地检测这些模式，并使用预读等技术来极大地提高读取性能。类似地，构建在页面缓存之上使得 Kafka 可以采用基于 sendfile 的网络传输，避免额外的数据复制。为了与吞吐量测试保持一致，我们还将 Kafka 配置为 fsync 每条消息然后运行了相同的测试。

Pulsar 采用了一种与 Kafka 非常不同的缓存方法，其中一些源于 BookKeeper 的核心设计选择，即将 journal 和 ledger 存储分开。除了 Linux 页面缓存之外，Pulsar 还引入了多个缓存层，举例来说，BookKeeper bookie 上的预读缓存（我们的测试保留了 OMB 默认的dbStorage_readAheadCacheMaxSizeMb = 1024），托管 ledger（managedLedgerCacheSizeMB，在我们的测试中是 20% 的可用直接内存，即 12GB*0.2 = 2.4GB）。在我们的测试中，我们没有观察到这种多层缓存的任何好处。事实上，多次缓存可能会增加部署的总体成本，我们怀疑，为了避免前面提到的使用直接字节缓冲区带来的 Java GC 问题，这 12GB 的堆外使用中存在大量的填充。

RabbitMQ 的性能取决于生产者端交换和消费者端绑定到这些交换的队列。对于延迟实验，我们使用了与吞吐量实验相同的镜像设置，特别是直接交换和镜像队列。由于 CPU 瓶颈，我们无法驱动高于 38K 消息 / 秒的吞吐量，而且，基于这个速率度量延迟的任何尝试都显示出了性能的显著下降，p99 延迟几乎达到了 2 秒。

逐渐将吞吐量从 38K 消息 / 秒降低到 30K 消息 / 秒，我们获得了一个稳定的吞吐量，此时，系统资源似乎不存在过度利用。更好的 p99 延迟（1 毫秒）证实了这一点。我们认为，在吞吐量较高的情况下，在 3 个节点上复制 24 个队列的开销似乎对端到端延迟有严重的负面影响，而吞吐量小于 30K 消息 / 秒或 30MB/s（洋红色实线）时，RabbitMQ 可以提供比其他两个系统更低的端到端延迟。

通常，遵循最佳实践，RabbitMQ 可以提供界限内延迟。鉴于实验故意设置的延迟，消费者总是能跟上生产者，RabbitMQ 的消息管道效率归根结底是 Erlang BEAM VM 处理队列所需做的上下文切换的次数。因此，通过为每个 CPU 内核分配一个队列来限制这一点可以提供最低的延迟。此外，使用 Direct 或 Topic 交换允许对特定队列进行复杂的路由（类似于 Kafka 和 Pulsar 上专用于分区的消费者）。但是，直接交换提供了更好的性能，因为没有通配符匹配，这会增加开销，对这个测试来说，这是合适的选择。

图 13：Kafka、Pulsar 和 RabbitMQ 的端到端延迟，测量时 Kafka 和 Pulsar 的速率为 200K 消息 / 秒（消息大小 1 KB），RabbitMQ 的速率为 30K 消息 / 秒。注：延迟（毫秒）越低越好。

在本节的开始，我们已经讨论了 Kafka 在默认推荐 fsync 配置下的延迟结果（绿色实线）。在 Kafka 将每条消息 fsync 到磁盘（绿色虚线）的可选配置下，我们发现，Kafka 仍然比 Pulsar 延迟低，几乎一直到 p99.9 百分位，而 Pulsar（蓝色线）在更高的尾部百分位上表现更好。在 p99.9 及更高百分位上准确推断尾部延迟非常困难，我们相信，在 Kafka fsync 可选配置（绿色虚线）下

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

，考虑到生产者延迟似乎遵循相同的趋势，p99.9 延迟的非线性暴涨可以归因于涉及 Kafka 生产者的边缘情况。

延迟权衡

图 14：RabbitMQ 的端到端延迟：速率为 10K、20K、30K 和 40K 消息 / 秒时镜像队列（测试中使用的配置）与经典队列对比（不复制）。注：在这个图中，y 轴上的刻度是对数。

我们承认，每个系统在设计时都有一定的权衡。尽管对 Kafka 和 Pulsar 不公平，但我们发现，在不提供高可用性的配置下把 RabbitMQ 与 Kafka&Pulsar 进行比较很有趣，后两者都以较低的延迟为代价，提供了更强的持久性保证，并且可用性是 RabbitMQ 的三倍。对于某些用例而言（例如设备位置跟踪），这可能很有意义。在这种情况下，用可用性来换取更好的性能是可以接受的，特别是当用例要求实时消息传递并且对可用性问题不敏感时。我们的结果表明，当禁用复制时，RabbitMQ 可以在更高的吞吐量下更好地保持较低的延迟，不过提高后的吞吐量（100K 消息 / 秒）仍然远低于 Kafka 和 Pulsar 所能达到的水平。

尽管 Kafka 和 Pulsar 速度较慢（p99 百分位分别为大约 5 毫秒 和 25 毫秒），但它们提供的持久性、更高的吞吐量和更高的可用性，对于处理金融事务或零售库存管理等大规模事件流用例来说至关重要。对于需要较低延迟的用例，在负载不重的情况下，RabbitMQ 可以实现 大约 1 毫秒 的 p99 百分位延迟，这是因为消息只是在内存中排队，没有复制开销。