浏览本文须要 5 分钟

作者：Chris Bartholomew

前段时间，我在一篇博客中提到了 《抉择 Pulsar 而不是 Kafka 的 7 大理由》。之后我始终在筹备一份比拟 Kafka 和 Pulsar 的具体报告，并始终与 Pulsar 开源我的项目的用户交谈，同时也与咱们托管的 Pulsar 服务 —— Kafkaesque (https://kafkaesque.io/) 的用户交谈。

我发现上一篇文章中我脱漏了一些起因。所以，我顺便写了本篇后续，进行补充。

在补充之前，咱们先来疾速回顾一下上一篇文章中提到的 7 个起因：

• 流式解决和队列的合体。Kafka 或 RabbitMQ 在单个平台上都只能解决其中一种形式。而 Pulsar 就像一个合二为一的产品，能够同时解决实时流和音讯队列。
• 反对分区，但不是必须的。如果只须要一个主题，能够应用一个主题而无需应用分区。如果须要放弃多个消费者实例的解决速率，也不须要应用分区。
• 分布式的日志。Pulsar 日志是分布式的，能够程度扩大。因而不会保留在单台服务器上，任何一台服务器都不会成为整个零碎的瓶颈。
• 无状态的 broker。云原生利用程序开发的现实场景，数据的散发和保留互相独立。
• 原生反对跨地区复制，而且配置简略。无论是全局分布式应用程序还是灾备计划，任何人都能够通过 Pulsar 搞定。
• 稳固的体现。基准测试表明，Pulsar 能够在提供较高吞吐量的同时放弃较低的提早。
• 齐全开源。不论是与 Kafka 类似的个性，还是 Kafka 没有的个性都是开源的。

以上便是之前提到的 7 个起因。如果你想理解对于以上几点的具体内容，能够查看结尾提到的文章。这些起因仿佛曾经很多了，然而我发现了更多。

多租户解决

上一篇文章中，我应该多谈谈多租户。Pulsar 对多租户的反对是一个很重要的个性。在企业中，音讯基础架构会被多团队、多我的项目应用。为每个团队（我的项目）别离保护一个独立的音讯零碎集群代价过高且难以保护。

Pulsar 能够有多个租户，这些租户能够有多个命名空间，以放弃内容程序。再加上每个命名空间的访问控制、配额、速率限度等，能够设想，未来咱们能够只应用一个集群就能解决多租户问题。其实不仅咱们思考到这个问题，Kafka 也会思考。在 Kafka 改良倡议（KIP）KIP-37 中能够看到与此相关的内容。这个问题曾经探讨了一段时间了。

Quorum 复制

接下来，我会讲到很多细节。要想确保音讯不失落，消息传递零碎会配置每条音讯生成 2 或 3 个正本，以防出错。Kafka 应用 follow-the-leader 模型来实现这一点。Leader 存储音讯，而 follower 复制 leader 上的音讯。

一旦有足够多的 follower 确认曾经实现了复制，Kafka 就“快乐”了。Pulsar 应用 Quorum 模型。它把音讯发送给一堆节点，一旦有足够多的节点确认它们曾经接管到音讯，Pulsar 就很“快乐”。

Quorum 复制更加专制，没有这种 leader-follower 层次结构。所有选票均等时，少数胜利。但这与技术无关。重要的是，随着工夫的推移，Quorum 复制偏向于提供更统一的行为。

这或者能够解释为什么 Pulsar 具备更统一的提早性能。如果你想理解对于 Kafka 和 Pulsar 提早的详细信息，请查看我的这篇博客（文章很长，别说我没揭示你哦）

事实上，Kafka 也始终在思考应用 Quorum 复制来改善提早一致性。对于此，能够查看 KIP-250 中的探讨。

分层存储

像 Kafka 这样的流解决零碎，其一大长处在于它可能重放曾经被生产的音讯。如果你第一次见到就很喜爱这些音讯，则能够进行重播以更正某些内容，或围绕它们构建新的应用程序，这也是很乏味的。

如果你十分喜爱这些音讯，想把它们永远保留下来，那该怎么办？比方，如果你在做事件溯源。这听起来很不错，但永恒可是一段很长的工夫，而且永恒存储音讯也可能很贵，特地是存储在高性能固态硬盘上。这些硬盘须要维持音讯零碎保持良好的运行状态。

如果能把那些旧音讯（那些当前可能会再用到的音讯）转移到绝对便宜的存储解决方案中，是否可行呢？如果能够应用像 Amazon S3 存储桶这样便宜的云存储，那岂不是很棒吗？你可能曾经猜到我要说什么了。

借助 Pulsar 分层存储，你能够把那些旧音讯主动推送到简直有限的、便宜的云存储中，而后像检索新音讯一样执行相干操作。我敢打赌，Kafka 心愿领有该性能。没错，他们会的。在 KIP-405 中能够看到相干探讨。

端到端加密

显然，平安是很重要的，谁都不心愿信息安全被偷窥。当然，你会在客户端和消息传递零碎之间应用 TLS（在传输过程中加密）。这样做时，消息传递零碎必须解密该连贯，以便理解客户端想要表白的内容。

而后，它把未加密的音讯保留在磁盘上。当然，你会保持对磁盘进行加密，这样即便磁盘被偷，音讯依然是平安的（动态加密）。但在这两种状况下，消息传递零碎都须要有数据的密钥。如果不是这样，那就是在解决一大堆莫名其妙的天书。

许多状况下，这种级别的加密曾经足够好了，然而如果你想要确保没有人能够偷窥你的音讯，则须要进行端到端加密。生产者在发送音讯之前应用与接管音讯的使用者共享的密钥对音讯进行加密。当音讯保留在音讯零碎的磁盘上时，就会被加密，而音讯零碎没有密钥。消息传递零碎能够实现它的工作，然而你的音讯对于消息传递零碎来说是就像天书一样，所以是非常平安的。

Pulsar 能够在其 Java 客户端中进行端到端加密。Kafka 始终在 KIP-317 中探讨这一操作。

Broker 均衡

Pulsar broker 是无状态的。组件无状态是件十分棒的事件，当一个组件过载时，你能够增加另一个组件来解决负载。当新客户端连贯时，能够将它们定向到新实例。但这并不能帮忙到第一次被重载的实例。你须要将一些工作从重载实例转移到新的实例上。换句话说，须要从新均衡负载。

Pulsar 会主动进行 broker 负载平衡。它监督 broker 的 CPU、内存、网络（不是磁盘，我提到的代理是无状态的）的应用状况，并调整负载以保持平衡。这意味着你不须要在单个 broker 热点时扩容 broker 集群，除非 broker 集群服务能力达到下限。

你也能够应用 Kafka 进行代理负载平衡。然而，你必须多装置一个程序，例如 LinkedIn 的 Cruise Control。或者也能够应用 Confluent 的负载平衡器工具（这款工具是须要付费的）。

社区和生态系统

有人批评我没有提到 Kafka 社区和生态系统的规模和丰盛水平。这个批评很中肯。在社区和生态系统类别中，Kafka 的确比 Pulsar 做得好。作为一个开源我的项目，Kafka 曾经创始了 5 年，所以它有一个更大的社区，有更多相干的我的项目，并且在 Stack Overflow 上有更多相干的问题与答案。

随着大家一直奉献新的组件和周边集成，Pulsar 社区日益发展壮大，Slack 社区的小伙伴们都很敌对，也乐于助人。我还想补充一下：Pulsar 在许多方面受到 Kafka 的启发，并且站在了伟人 Kafka 的肩膀上。Kafka 我的项目和社区值得称赞与尊重。有时候听起来像是我不尊重 Kafka，其实我很尊重 Kafka，我只是对 Pulsar 更有好感罢了。

KAFKA 的正当替代品

在这篇文章和上一篇文章中，我列举了 12 条抉择 Pulsar 的理由。更酷的是，我发现随着对 Pulsar 理解的加深，我总能找到新的理由。因而，我可能还会写第三篇和这个主题相干博客。敬请关注。

我认为 Pulsar 是 Kafka 的正当替代品。Pulsar 反对 Kafka 的大部分性能，而且 Pulsar 有更多劣势（目前我列举了 12 个）。理解 Pulsar 的人越多，它的发展势头就越大。如果你正在评估流和 / 或队列零碎，考虑一下 Apache Pulsar 吧。

想要随时把握 Pulsar 的研发停顿、用户案例和热点话题吗？快来关注 Apache Pulsar 和 StreamNative 微信公众号，咱们会在第一工夫和您分享 Pulsar 的所有。

点击 链接，可查看英文版。