Apache Kafka、Apache Pulsar和RabbitMQ性能测试对比

Apache Kafka、Apache Pulsar和RabbitMQ都可以用作消息中间件平台，可对比的项目非常多，但是通常最关心的就是性能。在本文中，将专注于系统的吞吐量和延迟，因为这些是生产中事件流系统的主要性能指标。吞吐量测试尤其可以衡量每个系统在利用硬件（特别是磁盘和CPU）方面的效率。延迟测试可衡量每个系统与实时消息传递之间的接近程度，其中包括高达p99.9％的尾部延迟，这是实时和关键业务系统以及微服务架构的核心要求。

从测试结果来看，Kafka提供了最佳的吞吐量，同时提供最低的端到端延迟，最高可达p99.9％。在较低的吞吐量下，RabbitMQ传递消息的延迟非常低。

	Kafka	Pulsar	RabbitMQ（镜像）
峰值吞吐量	605MB/s	305MB/s	38MB/s
p99延迟（毫秒）	5毫秒（200MB/s负载）	25毫秒（200MB/s负载）	1ms*（减少至30MB/s的负载）

注意：RabbitMQ延迟在吞吐量高于30MB/s时会显著上升。此外，在更高的吞吐量下，镜像的影响非常明显，而仅使用传统队列而不进行镜像，则可以实现更好的延迟。

本文的结构会首先介绍使用的测试框架，然后介绍测试平台和工作负载。最后将使用各种系统和应用指标对结果进行解释。所有这些都是[开源]的，因此好奇的开发者可以自己复制结果，也可以更深入地研究所收集的Prometheus指标。与大多数基准测试一样，性能测试是基于一组特定的工作负载/配置的。当然开发者也可以使用自己的工作负载/配置进行比较，以了解如何切换为生产环境。

背景

首先简要介绍每个系统，以了解它们的高级设计和架构，并研究每个系统所做出的取舍。

Kafka是一个开源的分布式事件流平台，是Apache软件基金会五个最活跃的项目之一。Kafka的核心是一个可复制的、分布式的、持久化的提交日志，用于为事件驱动的微服务或大规模流处理应用提供支持。客户端直接向/从代理集群生成或消费事件，代理集群将事件持久化到基础文件系统，并且还自动在集群内同步或异步复制事件，以实现容错和高可用性。

Pulsar是一个开源的分布式发布/订阅消息系统，最初是为队列场景而设计的。最近，它还添加了事件流功能。Pulsar被设计为（几乎）无状态代理实例层，这些实例连接到单独的BookKeeper实例层，该实例实际负责读/写并有选择地持久化存储/复制消息。同类系统中Pulsar并不是唯一的，还有例如Apache DistributedLog和Pravega，它构建于BookKeeper之上，可以提供一些类似Kafka的事件流功能。

BookKeeper是一个开源分布式存储服务，最初设计为Hadoop NameNode的预写日志。它在称为bookies的服务器实例之间以账本的形式提供消息的持久化存储。每个bookie出于恢复的目的将每个消息同步写入本地日志，然后异步写入其本地索引存储中。与Kafka代理不同，bookies不会相互通信，而BookKeeper客户端负责使用仲裁协议在bookies之间复制消息。

RabbitMQ是一个开源的传统消息中间件，该中间件实现了AMQP消息标准，可满足低延迟队列场景的需要。RabbitMQ由一组代理进程组成，这些代理进程托管用于将消息发布到其中的交换器以及用于消费消息的队列。可用性和持久性是所提供的各种队列类型的属性。传统队列提供最少的可用性保证。传统镜像队列将消息复制到其他代理，并提高可用性。通过最近引入的[仲裁队列]可以提供更强的持久性，但是会降低性能。由于本文关注性能，因此将评估限制为传统队列和镜像队列。

分布式系统的持久性

单节点存储系统（例如RDBMS）依赖于对磁盘的全同步写入来确保最大的持久性。但是在分布式系统中，持久性通常来自复制，数据的多个副本相互独立。全同步数据只是在故障确实发生时减少故障影响的一种方式（例如更频繁地进行同步可能会缩短恢复时间）。相反，如果足够多的副本失败，则无论全同步与否，分布式系统都可能无法使用。因此，是否进行全同步只是一个问题，即每个系统选择依赖于什么来进行复制设计。尽管有些紧密依赖于写入磁盘的数据，因此每次写入都需要同步，但其他一些则在设计中处理了这种情况。

Kafka的复制协议经过精心设计，可通过跟踪已同步到磁盘的内容和未同步到磁盘的内容来确保一致性和持久性，而无需全同步写盘。通过少做一些假设，Kafka可以处理范围更广的故障，例如文件系统级损坏或意外的磁盘资源调配，并且不会将不知道的数据的正确性视为理所当然。Kafka还能够利用操作系统来批量写入磁盘，以提高性能。

目前无法明确确定BookKeeper是否在不全同步每个写入的情况下提供相同的一致性保证，特别是在没有同步磁盘持久性的情况下是否可以依靠复制来实现容错。根据检查以及BookKeeper实现了分组的全同步算法这一事实，可以认为它确实依赖于全同步写入来确保其正确性，但是这个结论还需进一步确认。

由于这可能是一个有争议的话题，因此测试过程中在两种情况下都给出了结果，以确保尽可能公平和完整，尽管使用全同步运行Kafka极为罕见，也没有必要。

基准测试框架

对于任何测试，大家都会关注使用了什么框架，以及它是否公平。为此，本次测试选择了[OpenMessaging Benchmark Framework]（OMB），该框架最初是由Pulsar贡献者开发的。OMB入门容易，它具有基本的工作负载规范，测试结果的指标收集/报告汇总，对3个选定消息系统的支持以及针对每个系统定制的模块化云部署工作流。但需要注意的是，Kafka和RabbitMQ的实现确实存在一些问题，影响了这些测试的公平性和可重复性，因此本次测试做了一些修正

OMB框架调整

测试软件平台已升级到Java 11、Kafka 2.6、RabbitMQ 3.8.5和Pulsar 2.6（当前的最新版本），通过使用Grafana/Prometheus监控堆栈，跨消息系统、JVM、Linux、磁盘、CPU和网络捕获指标，显著增强了跨3个系统的监控功能。这对于不仅能够报告结果而且能够解释结果至关重要。本次测试增加了对仅生产者测试和仅消费者测试的支持，并支持生成/排出积压，同时还修复了当主题数小于生产者工作节点数时生产者比率计算的一个严重错误。

OMB Kafka驱动调整

本次测试修复了Kafka驱动中的一个严重Bug，该Bug使Kafka生产者无法使用TCP连接，并限制了每个工作实例的单个连接的瓶颈。与其他系统相比，此修复使Kafka的数量合理，即它们现在都使用相同数量的TCP连接与各自的代理进行通信。还修复了Kafka消费者驱动中的一个严重Bug，该Bug中偏移量的提交过于频繁且同步导致性能下降，而其他系统则异步进行。测试还调整了Kafka消费者获取大小和复制线程数，以消除高吞吐量时消息获取的瓶颈，并配置与其他系统同等的代理。

OMB RabbitMQ驱动调