尝试扩展 Apache Kafka？考虑使用 Apache Pulsar

如今，即使是最基本的网络和移动应用程序也会消耗大量数据。交换和处理这些数据的关键是一个由事件驱动架构支持的消息传递系统。

事件驱动系统使消息传递解决方案和处理具有可扩展性和异步性。异步系统可以处理更多请求，因为每个请求都在后台处理。

当向服务器发出请求时，它被添加到队列中，处理器将在队列中读取它。这使组织能够通过在单独的集群中处理请求来构建每秒接受数十万甚至数百万请求的系统。

该行业已经产生了多种消息代理系统和主题驱动的发布-订阅(pub-sub) 平台，它们遵循这种事件和消息驱动的格式。 Apache Kafka和Apache Pulsar是分布式消息传递和流系统的两个广泛使用的例子。

Kafka 和 Pulsar 都是基于发布-订阅模式构建的，您可以使用该模式将消息传递扩展到数千个连接的客户端。两者都提供持久存储模型以确保消息不会丢失，并且都使用分区来存储和处理消息。

虽然 Kafka 和 Pulsar 在很多方面都很相似，但它们在功能上有一些显着差异——尤其是在管理大量数据、创建实时应用程序和大规模开发方面。

Kafka 提供了许多好处，但 Pulsar 对可扩展性和增长的支持是无与伦比的。而在成长的某个点，最优的选择是不再尝试优化 Kafka，而是与其分道扬镳。在这里，我们将比较 Kafka 和 Pulsar 之间的差异，展示在使用 Kafka 时为了可扩展性而合乎逻辑的下一步是如何切换到 Pulsar。

Apache Kafka 应用程序面临的挑战

Kafka 是软件架构中分布式发布-订阅模式的事实。使用 Kafka 的组织能够处理数千条消息并将消息同时广播给多个消费者。

Kafka有几个好处，但在尝试扩展时它也有一定的局限性。让我们探讨一下您在尝试扩展使用 Apache Kafka 构建的应用程序时将面临的一些挑战。

存储限制

Kafka 的架构带来了您在 Kafka 中扩展应用程序时将面临的第一个挑战：存储。

有状态代理是组织发现难以扩展的第一个原因。 Kafka 中的数据存储在leader node中，而数据的分区存储在本地磁盘上。数据与节点相关联，Kafka 中的代理是有状态的。这意味着一旦领导节点达到最大存储容量，除非增加基础设施存储，否则集群将无法接受更多消息。这具有挑战性，因为在不断增长的环境中，集群将需要多次升级。

克服这一挑战的一种方法是购买一个非常昂贵的大型存储集群。

此外，基于这种架构，一旦平台达到最大存储或内存限制，它就不能接受新的传入消息。这可能会导致关键业务应用程序的巨大损失。 Kafka 的架构旨在接受和广播大量消息。长期数据存储不是优先事项。因此，扩展 Kafka 应用程序非常具有挑战性，因为它无法提供您需要的存储——至少在不付出高昂代价的情况下是这样。

消息处理的问题

管理 Kafka 具有挑战性，因为它不包含活动监控、处理消息和数据持久化所需的功能。

Kafka 在无头消息广播系统中大放异彩，您无需在传递消息之前改变消息。但是，假设您需要在将消息转发给消费者之前对其进行处理；这需要依赖额外的平台，这使得使用 Kafka 处理消息更具挑战性和复杂性。

此外，上面列出的其他平台的参与显着增加了数据传输系统的复杂性，因为流媒体平台的每个组件都需要维护并且具有适用于整个集群的限制。此外，Kafka 集群的数据和消息持久性有限，因为您的数据需求会随着时间的推移而增长。

复杂的客户端库

企业主要使用 Kafka 来提供流媒体服务。流式 API 是在发布-订阅消息传递之上编写的，以支持独特的业务案例。 Kafka Streams API 是一个独立的产品，提供针对企业客户的高级功能。 Kafka Streams 最显着的特性， 事务，帮助企业确保消息流产生的输出的一致性。出于这个原因，Kafka 为每个用例提供了两个单独的 API。

例如，Kafka Streaming 库使企业能够提供“恰好一次”的消息传递。 Kafka 和 Pulsar 提供的交付保证是：

• 至少一次
• 最多一次
• 正好一次

“exactly once”传递保证对于每条消息，都会有一个关联的输出，这保证了消息在消费者崩溃的情况下得到处理。然而，这对于Consumers API来说是不可能的，它允许应用程序从 Kafka 集群中的主题读取数据流，需要您在平台中编写大部分功能。这使得很难将单个客户端库用于您的业务所需的所有功能，这在您大规模工作时是不可持续的。

进入脉冲星

对于上面强调的每个 Kafka 限制， Pulsar都有一个解决方案。以下部分概述了 Pulsar 的一些优势。

持久数据存储

Pulsar 提供了 Kafka 提供的消息流和发布功能，但增加了将数据持久化的能力。

Pulsar 使用 Apache Bookkeeper 提供数据存储持久性。 Bookkeeper 维护数据并帮助卸载集群外的数据持久性。您可以使用 AWS S3 等其他数据存储介质来存储数据并扩展到本地磁盘的限制之外，这意味着您可以轻松扩展您的应用程序而无需担心存储问题。

此外，Pulsar 还包括分层存储功能，有助于在热存储和冷存储选项之间移动数据；然后，只要业务需要，数据就可以存储在冷存储中。集群不需要持续更改存储选项的基础设施大小。

Pulsar 还通过使一部分数据不可变，自动将较旧的消息从 Bookkeeper 移动到更便宜的冷存储选项。不可变段可以移动到更便宜的存储中，有效地使 Pulsar 能够接受无限量的数据。

开发者经验

从开发人员的角度来看，Pulsar 为所有主要语言（Java、Python、Go 和 C#）提供了一个集成的、简单的客户端库。这些库可帮助开发人员快速开始使用该平台，这是大规模开发和发布应用程序的关键。 Pulsar 的二进制协议根据需要扩展客户端库的功能，使库适合增长。 （这里是可用的和官方支持的Pulsar 客户端库的列表。 ）

脉冲星函数

Pulsar Functions是一种开箱即用的功能，使开发人员能够编写自定义代码来处理消息流中的消息，而无需部署 Apache Heron、Apache Flink 或 Apache Storm 等系统。

Pulsar Functions 在无服务器连接器框架 Pulsar IO 中使用，使得从 Pulsar 移动数据和向 Pulsar 移动数据变得更加容易。这个开箱即用的系统使 Pulsar 能够连接到外部 SQL 和 NoSQL 数据库，例如 Apache Cassandra。

此外，此消息处理是流原生的，这意味着消息在交付给消费者之前在集群内部进行处理和转换。由于 Pulsar Functions 是 Pulsar 消息传递系统的计算基础设施，它们支持业务级目标，包括开发人员生产力、轻松的故障排除和操作简单性——这些品质在大规模工作时对应用程序和团队性能至关重要。

可扩展性

除了上述功能和服务及其对可扩展性的影响外，Pulsar 还提供各种功能，使其成为满足企业消息流和发布需求的可扩展选项。

Pulsar 的异地复制特性使 Pulsar 具有高度可扩展性。该集群将数据复制到全球多个位置，以备灾难导致应用程序崩溃时使用。复制支持同步和异步。与同步复制相比，异步复制速度更快，但提供的数据一致性保证更少。

Pulsar 使用一个 broker-per-topic 的概念，确保同一个 broker 处理一个主题的所有请求。 Pulsar 架构展示了与 Kafka 集群相比，基于代理的方法如何提高系统的性能。

包起来

Kafka 和 Pulsar 有一些相似之处，但在选择要使用的平台时也有一些值得考虑的根本差异——尤其是当您需要可扩展性时。

Kafka 的架构、存储能力和可用性提出了许多挑战，这些挑战可能会抑制组织的发展能力。尝试将你的 Kafka 集群扩展到一个点之外变得昂贵，而且往往比它的价值更麻烦。从存储数据的方式到支持消息转换的方式，Pulsar 是为可扩展性而构建的 Kafka 的下一代统一挑战者。

了解基于 Apache Pulsar 构建并作为完全托管服务交付的 DataStax Astra Streaming 。

玛丽·格里格斯基 (Mary Grygleski)。 Mary 是 DataStax 的流媒体开发倡导者。她专注于开发 Java、开源和云技术（包括云原生、无服务器、事件驱动、微服务和反应式架构）的社区宣传和外展活动。