在Kafkaesque，我们的使命是使开发人员能够使用与云无关的高性能消息传递技术，使其易于所有人使用，从而使他们能够构建云原生的分布式应用程序。开发人员希望编写分布式应用程序或微服务，但不希望管理复杂的消息基础结构或被某个特定的云供应商所困扰。他们需要一个可行的解决方案。
当您着手构建最佳的消息传递基础结构服务时，第一步是选择正确的基础消息传递技术。有很多选择，从RabbitMQ，ActiveMQ和NATS等各种开源项目到IBM MQ或Red Hat AMQ等专有解决方案。当然，还有Apache Kafka，它几乎是流的同义词。但是我们没有选择Apache Kafka，而是选择了Apache Pulsar。
那么，为什么我们要使用Apache Pulsar构建消息服务？有几个原因。这是我们选择Apache Pulsar而不是Apache Kafka的7大理由。
1.流和排队在一起
Apache Pulsar就像两个产品合而为一。它不仅可以处理像Kafka这样的高速率，实时的用例，而且还支持标准的消息队列模式，例如竞争的用户，故障转移订阅和简单的消息散出。Apache Pulsar自动跟踪主题中客户端的读取位置，并将该信息存储在其高性能分布式分类帐Apache BookKeeper中。
与Kafka不同，Apache Pulsar可以处理许多像RabbitMQ传统排队系统的用例。因此，您无需运行两个系统：一个实时流传输，一个系统进行排队，而使用Pulsar来运行一个系统来运行。
2. 分区，但不是必须分区
如果您使用Kafka，则会了解分区。所有主题都在Kafka中划分。分区很重要，因为它可以增加吞吐量。通过将工作分散在各个分区之间，从而在多个代理之间进行分散，单个主题topic可以处理的比率提高了。但是，如果您有一些不需要很高吞吐量的主题topic该怎么办。在这些简单的情况下，不必担心分区以及随之而来的API和管理复杂性。
好吧，使用Apache Pulsar可以这么简单。如果您只需要一个主题，请使用topic。您不必指定分区的数量，也不必考虑该主题可能有多少个使用者。通过Pulsar 订阅，您可以在一个主题上随心所欲地添加任意数量的消费者。如果您的消耗性应用程序无法跟上进度，则只需使用共享订阅即可在多个使用方之间分配负载。
而且，如果您确实需要分区主题的性能，也可以这样做。如果您需要，Pulsar会对主题进行分区，但前提是您需要它们。
3.日志很好，分布式分类帐更好
Kafka团队因日志是实时数据交换系统的出色抽象这一见解而值得赞扬。由于日志仅是追加的，因此可以快速将数据写入日志，并且由于日志中的数据是顺序的，因此可以按写入顺序快速提取数据。顺序读写速度很快，随机不是。持久性存储交互是任何提供数据保证的系统中的瓶颈，而日志抽象使这种方式尽可能高效。
简单的日志很好，但是一旦日志变大，它们就会给您带来麻烦。在单个服务器上安装日志成为一个挑战。如果装满了您需要横向扩展怎么办？如果存储日志的服务器发生故障并且需要从副本中重新创建，会发生什么？将大型日志从一台服务器复制到另一台服务器虽然高效，但仍需要花费很长时间。如果您的系统尝试在保持实时数据同步的同时执行此操作，那么这将是一个很大的挑战。在博客文章《从前边的故事：支持Apache Kafka的支持中学到的教训》中查看博客文章“添加新的经纪人可带来糟糕的业绩” 。
Apache Pulsar通过将日志分成多个段来避免复制大型日志的问题。当使用Apache BookKeeper作为存储层写入数据时，它将这些段分布在多个服务器上。这意味着日志永远不会存储在单个服务器上，因此单个服务器永远不会成为瓶颈。失败场景更易于处理，向外扩展很容易。只需添加另一台服务器。无需重新平衡。
4.无状态消息代理（计算与存储分离）
无状态是任何构建云原生应用程序的人都喜欢的音乐。无状态组件可以快速启动，可互换并且可以无缝扩展。如果消息代理是无状态的，那不是很好吗？
Kafak消息代理并非没有状态。每个代理均包含其每个分区的完整日志。如果一个代理服务器失败了，则不是任何一个其他消息代理服务器都可以接管它的。如果负载太高，则不能简单地添加另一个代理。代理必须同步其他包含其分区副本的代理的状态。
在Apache Pulsar架构中，代理是无状态的。是的，你听到的是对的。完全无状态的系统将无法持久保存消息，因此Apache Pulsar确实维护了状态，只是不在代理中。在Pulsar体系结构中，数据代理与数据存储是分开的。代理从生产者那里接收数据并将数据发送给消费者，但是数据存储在Apache BookKeeper中。
由于Pulsar代理是无状态的，因此如果负载很高，则只需添加另一个代理。代理服务器迅速启动并立即开始工作。
5.简单的地理复制
地理复制是Pulsar的一流功能。它不是螺栓连接或专有附件。Pulsar在设计时考虑了地理复制。配置它很容易，并且可以正常工作。因此，无论是全球分布式应用程序还是灾难恢复方案，都可以使用Pulsar进行设置。无需博士学位。
6.始终更快
基准测试表明，Pulsar提供了更高的吞吐量以及更低和更一致的延迟。越快越一致越好。还有什么要说的？
7.都是APACHE开源的
Pulsar具有许多与Kafka相同的功能，例如地理复制，流内消息处理（Pulsar函数），输入和输出连接器（Pulsar IO），基于SQL的主题查询（Pulsar SQL），架构注册表等作为功能，Kafka不具备分层存储和多租户的功能。所有这些功能都是Apache开源项目的一部分。
在KAFKA上选择APACHE PULSAR的5个更多理由：
1.与多租户相处
即使您不打算构建托管的Pulsar服务（以及既然我们已经为您构建了一个服务，您为什么还要这么做？），除非您是一个隐士，否则会有多个团队使用您的消息传递来从事多个项目基础设施。必须为每个团队或项目建立集群是一件很痛苦的事情。
使用Pulsar，您可以有多个租户，而这些租户可以具有多个命名空间，以保持一切井井有条。再加上每个命名空间的访问控制，配额和速率限制，您可以想象一个未来，我们将仅使用一个集群就能相处融洽。我们不仅可以想象这个未来，而且卡夫卡也可以想象。您可以在“ Kafka改进建议（KIP）KIP-37”中阅读有关内容。现在已经讨论了一段时间。
2.复制有法定人数吗？
您想确保消息不会丢失，因此您将消息传递系统配置为为每条消息制作2或3个副本，以防出现问题。Kafka使用领导者模型来做到这一点。领导者存储消息，而跟随者复制它。一旦有足够的追随者承认他们已经掌握了，卡夫卡就会很高兴。Pulsar使用法定人数模型。它将消息发送到一堆节点，一旦它们中的足够多的人确认已收到消息，Pulsar就会感到高兴。
没有这个领导者跟随者的层次结构，仲裁复制更加民主。多数总是赢，所有选票均等。但这与技术无关。重要的是仲裁复制会随着时间的流逝而给出更一致的行为。这可能可以解释为什么Pulsar可以提供更一致的延迟性能。如果您想了解有关Kafka和Pulsar延迟的详细信息，请查看我撰写的这篇博客文章。（很长。不要说我没有警告过您。）哦，Kafka也一直在考虑使用仲裁复制来提高延迟一致性。查看KIP-250进行讨论。
3.分层存储，实现事件溯源
像Kafka这样的流媒体系统的一大优点是它具有重放已消耗的消息的能力。如果您是第一次喜欢这些消息，则可以重播它们以更正某些内容或围绕它们构建新的应用程序。如果您非常喜欢这些消息，而又想一直保留下去，该怎么办？举例来说，假设您正在进行事件来源。这听起来像是个好主意，但永远是一个漫长的时光，永远存储消息会变得昂贵，尤其是如果将消息存储在那些使消息系统嗡嗡作响的高性能固态硬盘上。
如果您可以将这些旧消息（因为有一天可能会需要保留）而转移到便宜的存储解决方案中，这是否有意义？而且，如果您可以使用像Amazon S3存储桶这样廉价的云存储，那不是很好吗？您可能会猜到我要去哪里。借助Pulsar 分层存储，您可以将那些尘土飞扬的旧消息自动推送到几乎无限的廉价云存储中，并像处理这些新的，即时的消息一样检索它们。我敢打赌，Kafka希望拥有该功能。你猜对了，他们会的。它在KIP-405中进行了描述。
4.端到端加密和GOBBLEDYGOOK
显然，安全性很重要，并且您想防止邮件被窥视。当然，您将在客户端和消息传递系统之间使用TLS（在传输过程中加密）。当您这样做时，消息传递系统必须解密该连接，以便它可以弄清客户端要说的内容。然后它将把未加密的消息保存在磁盘上。当然，您将坚持对磁盘进行加密，这样，如果有人偷了磁盘，则您的消息将是安全的（静态加密）。但是在这两种情况下，消息传递系统都具有数据的密钥。如果不是这样，它将处理令人费解的流语言。
在许多情况下，这种加密级别足够好，但是如果您要确保绝对没有人可以窥视您的消息，则需要进行端到端加密。生产者使用与接收消息的使用者共享的密钥在发送消息之前对消息进行加密。当邮件保存在邮件系统的磁盘上时，将被加密，并且邮件系统没有密钥。邮件系统可以完成其工作，但是您的邮件对邮件系统来说是超级安全的。
Pulsar可以在其Java客户端中进行端到端加密。Kafka一直在谈论在KIP-317中执行此操作。
5.消息代理平衡法
Pulsar会自动为您代理代理负载平衡。它监视CPU，内存和网络（不是磁盘，我是否提到代理是无状态的）代理的使用情况，并将移动负载以保持平衡。这意味着您不必添加新的代理，直到您用完所有代理的容量，这不是因为其中一个正在运行。
您可以使用Kafka进行代理负载平衡。但是，您将必须安装另一个软件包，例如LinkedIn的Cruise Control。或者，如果您愿意（最终）付款，则可以使用Confluent的再平衡器工具。
社区与生态系统
在社区和生态系统类别中，Kafka击败了Pulsar。Kafka作为开放源代码项目有5年的领先优势，因此只能说它会有更大的社区，更多相关项目以及更多关于Stack Overflow的答案。
我只能说Pulsar社区正在发展，人们定期地贡献新的组件和集成，并且社区Slack频道上的人们都很友好和支持。实际上，我还能说一件事。显然，许多Pulsar受到Kafka的启发和启发，并且Pulsar站在巨人的肩膀上。Kafka项目和社区值得称赞和尊重。我知道有时候听起来好像我不尊重卡夫卡，但是我真的对Pulsar感到兴奋。