为什么选择Pulsar而非Kafka

这篇文章给大家介绍为什么选择 Pulsar 而非 Kafka ，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。

创新互联是一家企业级云计算解决方案提供商,超15年IDC数据中心运营经验。主营GPU显卡服务器，站群服务器，成都服务器托管，海外高防服务器，服务器机柜，动态拨号VPS，海外云手机，海外云服务器，海外服务器租用托管等。

>>> 多租户处理 <<<

 Pulsar 对多租户的支持是一个很重要的特性。  在企业中，消息基础架构会被多团队、多项目使用。  为每个团队（项目）分别维护一个独立的消息系统集群代价过高且难以维护。

Pulsar 可以有  多个租户  ，这些租户可以有多个命名空间，以保持内容顺序。  再加上每个命名空间的访问控制、配额、速率限制等，可以想象，将来我们可以只使用一个集群就能处理多租户问题。  其实不仅我们考虑到这个问题，Kafka 也会考虑。    

>>> Quorum 复制 <<<

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

一旦有足够多的 follower 确认已经完成了复制，Kafka 就“高兴”了。  Pulsar 使用   Quorum 模型  。  它把消息发送给一堆节点，一旦有足够多的节点确认它们已经接收到消息，Pulsar 就很“高兴”。

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

这或许可以解释为什么 Pulsar 具有更一致的延迟性能。    

事实上，Kafka 也一直在考虑使用 Quorum 复制来改善延迟一致性。  关于此，可以查看   KIP-250   中的讨论。

>>> 分层存储 <<<

像 Kafka 这样的流处理系统，其一大优点在于它能够重放已经被消费的消息。  如果你第一次见到就很喜欢这些消息，则可以进行重播以更正某些内容，或围绕它们构建新的应用程序，这也是很有趣的。

如果你非常喜欢这些消息，想把它们永远保存下来，那该怎么办？  比如，如果你在做  事件溯源  。  这听起来很不错，但永久可是  一段很长的时间  ，而且永久存储消息也可能很贵，特别是存储在高性能固态硬盘上。  这些硬盘需要维持消息系统保持良好的运行状态。

如果能把那些旧消息（那些以后可能会再用到的消息）转移到相对便宜的存储解决方案中，是否可行呢？  如果可以使用像 Amazon S3 存储桶这样廉价的云存储，那岂不是很棒吗？  你可能已经猜到我要说什么了。

借助 Pulsar    分层存储  ，你可以把那些旧消息自动推送到几乎无限的、廉价的云存储中，然后像检索新消息一样执行相关操作。  我敢打赌，Kafka 希望拥有该功能。  没错，他们会的。

>>> 端到端加密 <<<

显然，安全是很重要的，谁都不希望信息安全被偷窥。  当然，你会在客户端和消息传递系统之间使用 TLS（在传输过程中加密）。  这样做时，消息传递系统必须解密该连接，以便了解客户端想要表达的内容。

 然后，它把未加密的消息保存在磁盘上。  当然，你会坚持对磁盘进行加密，这样即使磁盘被偷，消息仍然是安全的（静态加密）。  但在这两种情况下，消息传递系统都需要有数据的密钥。  如果不是这样，那就是在处理一大堆莫名其妙的天书。

许多情况下，这种级别的加密已经足够好了，但是如果你想要确保没有人可以偷窥你的消息，则需要进行端到端加密。  生产者在发送消息之前使用与接收消息的使用者共享的密钥对消息进行加密。  当消息保存在消息系统的磁盘上时，就会被加密，而消息系统没有密钥。  消息传递系统可以完成它的工作，但是你的消息对于消息传递系统来说是就像天书一样，所以是十分安全的。

Pulsar 可以在其 Java 客户端中进行  端到端加密  。    

>>> 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 的合理替代品 <<<

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

关于为什么选择 Pulsar 而非 Kafka 就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。

文章标题：为什么选择Pulsar而非Kafka
转载来于：http://scjbc.cn/article/ppjgpo.html