Kafka和Pulsar该如何选择？

Apache Kafka为大规模分布式消息传递设置了标准，但是Apache Pulsar有自己的一些巧妙技巧

如今，大规模可伸缩的发布/订阅消息传递实际上是Apache Kafka的同义词。Apache Kafka仍然是分布式流媒体应用程序的坚定的、开源的首选，无论您是添加apache storm或apache spark之类的东西进行处理，还是使用Apache Kafka本身提供的处理工具。但Kafka不是唯一的选择。

Apache Pulsar由Yahoo开发，现在是Apache软件基金会的一个项目，它将成为Apache Kafka多年来佩戴的消息传递的王冠。在许多情况下，Apache Pulsar提供了比Apache Kafka更快的吞吐量和更低的延迟，同时还提供了一个兼容的API，允许开发人员相对轻松地从Kafka切换到Pulsar。

人们应该如何在尊敬的坚定的Apache Kafka和暴发户Apache Pulsar之间做出选择？让我们看看他们的核心开源产品，以及核心维护者的企业版带来了什么。

Apache Kafka

ApacheKafka由LinkedIn开发并于2011年以开源的形式发布，它已经广泛传播开来，几乎成为许多人在考虑向架构中添加服务总线或发布/订阅系统时的默认选择。自从Apache Kafka问世以来，Kafka生态系统有了很大的发展，添加了Scheme Registry来强制Apache Kafka消息传递中的模式，Kafka Connect用于从其他数据源（如数据库）到Kafka的轻松流，Kafka Streams用于分布式流处理，最近的KSQL用于对Kafka主题执行类似SQL的查询(卡夫卡中的主题是特定频道的名称。）

过去几年中构建的许多实时管道的标准用例是将数据推入Apache Kafka，然后使用流处理器（如Apache Storm或Apache Spark）拉入数据、执行和处理，然后将输出发布到另一个主题以供下游使用。使用Kafka Streams和KSQL，您可以处理所有的数据管道需求，而不必随时离开Apache Kafka项目，当然，如果需要，您仍然可以使用外部服务来处理数据。

虽然从开发人员的角度来看，Apache Kafka一直都非常友好，但在操作上却有点鱼龙混杂。建立和运行一个小集群相对容易，但是维护一个大集群常常充满问题（例如，Kafka代理失败后的领导者分区交换）。

此外，通过一个名为MirrorMaker的实用程序来支持多租户的方法是让sre拔出头发的可靠方法。事实上，MirrorMaker被认为是这样一个问题，以至于像Uber这样的公司已经创建了自己的跨数据中心复制系统（uReplicator）。Confluent包括Confluent Replicator，作为其ApacheKafka企业产品的一部分。作为一个不得不维护MirrorMaker设置的人来说，很遗憾Replicator不是开源版本的一部分。

然而，在作战方面，这绝对不全是坏消息。在当前的ApacheKafka1.x系列中已经做了很多工作来减少运行集群的一些麻烦。最近出现了一些变化，使系统能够以更精简的方式运行包含20多万个分区的大型集群，并且在Kafka Connect中添加“死信”队列等改进使得识别和恢复数据源和接收器中的问题变得更加容易。我们还看到在Kubernetes上运行ApacheKafka的生产级支持（通过HelmCharts和Kubernetes运营商）。

早在2014年，Kafka的三位原始开发者（Jun Rao、Jay Kreps和Neha Narkhede）就成立了Confluent，该公司在其Confluent平台中提供了其他企业功能，如上述复制器、控制中心、其他安全插件以及通常的支持和专业服务。Confluent还有一个云产品Confluent cloud，它是一个完全管理的Confluent平台服务，运行在Amazon Web服务或Google云平台上，如果您不想自己处理运行集群的一些操作开销的话。

如果您被锁定在AWS中并使用Amazon服务，请注意Amazon已经引入了Amazon-Managed-Streaming for Kafka（MSK）的公共预览，这是AWS生态系统中完全管理的Kafka服务(还要注意的是，amazonmsk并不是与Confluent合作提供的，因此运行MSK并不能获得Confluent平台的所有特性，而只能获得开放源码apachekafka中提供的特性。）

Apache Pulsar

考虑到Apache软件基金会倾向于选择似乎重复功能的项目（您是否希望Apache Apex、Apache Flink、Apache Heron、Apache Samza、Apache Spark或Apache Storm满足您的定向非循环图数据处理需求？），在选择apachekafka作为消息传递需要的可信选项之前，您可以先看看Apache Pulsar成为顶级Apache项目的公告。

Apache Pulsar诞生于Yahoo，它的创建是为了满足组织的需求，而其他开源产品当时无法提供这些需求。因此，Pulsar从一开始就可以处理数百万个主题和分区，完全支持地理复制和多租户。

在封面下，Apache Pulsar使用apachebookkeeper来维护它的存储需求，但是有一个转折点：Apache Pulsar有一个称为分层存储的特性，这是非常重要的。分布式日志系统的一个问题是，虽然您希望数据尽可能长时间地保留在日志平台中，但磁盘驱动器的大小并不是无限的。在某个时刻，您可以决定删除这些消息，或者将它们存储在其他位置，如果将来需要，这些消息可能会通过数据管道重播。这是可行的，但操作起来可能很复杂。Apache Pulsar通过分层存储，可以自动将较旧的数据移动到amazons3、Google云存储或Azure博客存储，并且仍然向客户端呈现透明的视图；客户机可以从一开始就读取，就像所有消息都出现在日志中一样。

就像ApacheKafka一样，ApachePulsar为数据处理发展了一个生态系统（尽管它也为ApacheSpark和ApacheStorm提供了适配器）。Pulsar IO相当于Kafka Connect，可以作为源或汇连接到其他数据系统，Pulsar函数提供数据处理功能。SQL查询是通过使用Facebook开源Presto引擎的适配器提供的。

一个有趣的问题是，Pulsar函数和PulsarIO运行在一个标准的Pulsar簇内，而不是可能在任何地方运行的独立进程。虽然这降低了灵活性，但从操作的角度来看，确实使事情变得简单得多(有一种本地运行模式可能被滥用以在集群之外运行函数，但是文档特意说“不要这样做！”）

Apache Pulsar还提供了在集群内运行函数的不同方法：它们可以作为单独的进程、Docker容器或代理的JVM进程中运行的线程来运行。这与Apache Pulsar的部署模型有关，Apache Pulsar已经在生产中支持Kubernetes或中间层DC/OS。需要注意的一点是，Pulsar函数、Pulsar IO和SQL是Apache Pulsar相对较新的补充，因此如果您使用它们，应该会有一些锐利的优势。

还有一个有限的、仅限Java的、与Kafka兼容的API包装器，因此您可以潜在地将现有的Apache Pulsar应用程序集成到Apache Pulsar基础设施中。与生产解决方案相比，这可能更适合于探索性测试和临时迁移计划，但拥有它也不错！

与Confluent类似，雅虎ApachePulsar的开发者（MatteoMerli和SijieGuo）成立了一家分拆公司Streamlio，他们与ApacheHeron（Karthik Ramasamy和Sanjeev Kulkarni）的创始人共同创建了这家公司。Streamlio的企业级产品包括通常的商业支持和专业服务解决方案，以及一个封闭源代码管理控制台，但高效持久的多租户支持等是核心开放源代码产品的一部分。

选择 Kafka 还是 Pulsar?

Apache Kafka是一个成熟的、有弹性的、经过战斗测试的产品。它有几乎所有流行语言编写的客户机，以及Kafka Connect中用于不同数据源的大量受支持的连接器。由于Amazon和Confluent提供托管服务，很容易建立、运行和维护一个大型Kafka集群，这比前几年要容易得多。我将继续在新的项目中使用Apache Kafka，而且我很可能会在未来的许多年中这样做。

但是，如果您要构建一个消息传递系统，该系统从一开始就必须是多租户或地理复制的，或者需要大量的数据存储，再加上无论过去多久都需要轻松查询和处理所有这些数据，那么我建议您抛弃ApachePulsar。它绝对适合Apache Kafka可能遇到的一些用例，同时在分布式日志平台所需的核心特性方面也能很好地工作。