Pulsar和Kafka，哪一个更好？这篇博客文章探讨两者各自的利弊，非技术性准则，以找到解决业务问题的最佳工具。
当我为Confluent工作时，我的讨论通常围绕Apache Kafka及其生态系统进行。在过去的几年中，我对Pulsar唯一的疑问来自Pulsar的提交者和贡献者。他们问了我一些深层次的技术问题，以便能够解释Pu在哪里烂，以及为什么Pulsar是更好的选择。在Reddit等平台上对此主题的讨论通常是自以为是的，常常是不准确且残酷的。以下是我基于多年开源流媒体平台经验的观点。
Kafka与中间件，事件流和API平台
技术比较旨在指导人们选择适合其业务问题的正确解决方案和体系结构。没有万能的，也不应有偏见。选择适合该问题的工具。
但是，技术比较几乎总是有偏差的。即使作者不为供应商工作，而是“独立”顾问，但无论是有意还是无意，他或她仍可能对过去的经验和知识有偏见。尽管如此，从不同角度进行比较还是有用的，并且我们已经在互联网上的几个地方看到了Apache Pulsar的讨论，所以我想分享我对Kafka和Pulsar进行比较的个人看法。我为Confluent工作，后者是Apache Kafka及其生态系统背后的领先专家，因此请记住这一点，但是本文的目的不是提供意见，而是权衡事实而不是神话。
之所以进行所有这些比较，是因为客户希望了解何时使用哪种工具。
对于Pulsar对Kafka，情况略有不同。
为什么要比较Pulsar和Kafka？
在与潜在客户或客户交谈时，很少有人问我关于Pulsar的问题。公平地说，在最近几个月中，这个数字略有增加。由于功能集和用例的重叠，我猜这个问题在每15至20次会议上都会出现。但是，这似乎主要是由于互联网上的一些帖子声称，Pulsar在某些方面要比Kafka更好。对于相反的观点，没有事实检查，也没有什么材料（如果有的话）。
尽管我知道世界上有大量需要像Kafka或Pulsar这样的分布式消息传递技术的用户，但我还没有与一个认真考虑在生产中部署Pulsar的组织进行过交谈。但我也认为，Pulsar所谓的参考用户不是特别准确。
例如，他们的旗舰用户是中国大型科技公司腾讯，但腾讯是Kafka的庞大用户，而Pulsar的使用仅限于一个项目。腾讯每天通过Kafka处理数万亿条消息（以数字：10,000,000,000,000）。事实证明，腾讯使用Kafka的频率是Pulsar的1000倍（十万亿msg 天与数百亿msg 天）。腾讯团队更详细地讨论了其Kafka部署：腾讯PCG如何使用Apache Kafka每天处理10万亿条消息。
两种竞争性开源框架的比较
Apache Kafka和Apache Pulsar是两项令人兴奋且相互竞争的技术。因此，比较它们很有意义。
Apache Kafka和Apache Pulsar都具有非常相似的功能集。我建议您评估两个框架的可用功能，成熟度，市场采用率，开源工具和项目，培训材料，本地聚会的可用性，视频，博客文章等。您所在行业或业务问题的参考用例有助于做出正确的选择决定。
Confluent发表了这样的比较：“ Kafka与Pulsar与RabbitMQ：性能，体系结构和功能比较”。我参与了创建此比较。所以我们已经有了比较...
那么此博客文章是关于什么的？
我想从一些“Kafka vs Pulsar”论点中探索神话，我经常在博客文章和论坛讨论中看到这些论点。此后，我将给出除技术方面以外的更全面的比较，因为大多数Pulsar讨论都仅侧重于技术功能。
Kafka vs Pulsar –探索技术神话
下面讨论我遇到的一些神话。我同意其中一些观点，但也要用确凿的事实来反驳其他观点。当然，对于其中的某些陈述可能存在不同的观点。同样，这完全没问题。以下是我的观点。
误解1：“与Kafka相比，Pulsar具有与众不同的内置功能”？
真的。
如果将Apache Kafka与Apache Pulsar进行比较，则将其分层体系结构，排队和多租户之类的功能称为差异化因素。
但：
Kafka也具有许多与众不同的功能：
相比Pulsar仅需一半的服务器
数据仅保存到磁盘一次
数据仅在内存中缓存一次
经过实战检验的复制协议
零拷贝性能
事务处理
内置流处理
长期储存
正在进行的工作：ZooKeeper移除（KIP-500），这使得Kafka的操作和部署比Pulsar（具有Pulsar，ZooKeeper，BookKeeper和RocksDB的四部分架构）更易于操作和部署，除了使Kafka更具可扩展性之外，更具弹性，等等。）
工作中：分层存储（KIP-405），这使Kafka更具弹性和成本效益。
还要问自己：您是否真的应该将开放源代码框架或产品和供应商与它们的完整产品进行比较？
这是很容易增加新的功能，如果你没有为它提供任务关键型支持。不仅要评估清单中的功能，还要评估它们在生产场景中如何经过实战测试。与高质量实现相比，低质量并快速实现的“差异化功能”有多少？
例如：作为Kafka原生流处理引擎，花了几年的时间来实现和测试Kafka Streams。您真的要将此与Pulsar函数进行比较吗？后者是添加用户定义函数（UDF）的功能；与“实时流处理”没有任何关系。还是更像是Kafka Connect的核心功能“单一消息转换（SMT）”？只需确保a）将苹果与苹果（而不是苹果与橙子）进行比较，并且b）不要忘记考虑功能的成熟度。越强大和关键，它就应该越成熟……
Kafka社区花费了大量的精力来改善核心项目及其生态系统。仅Confluent，就有200多名全职工程师从事Kafka项目，其他社区组件，商业产品以及主要云提供商上的SaaS产品。
误解二：“Pulsar在中国有几个非常大的用户，如腾讯”？
真的。
但是：腾讯实际使用Kafka比使用Pulsar多。使用Pulsar的计费部门在腾讯中只占一小部分，而大部分核心业务使用的是Kafka，它们的架构类似于Global-Kafka，将1000多个经纪人组合到一个逻辑集群中。
始终对开源项目保持谨慎。查看“普通公司”的成功案例。仅仅因为科技巨头使用它，并不意味着它会很好地为您的公司工作。过去有多少《财富》 2000强公司分享了有关Pulsar的成功案例？
在科技巨头之外寻找证明点！
科技巨头以外的证明点有助于获得他人的见识和教训。不是来自软件供应商。Kafka网站提供了许多有关关键任务部署的示例。更令人印象深刻的是：在过去的旧金山，纽约和伦敦的Kafka峰会上，每年来自不同行业的各种企业都会展示其用例和成功案例。包括财富2000强企业，中型企业和初创企业。
仅举一个在Kafka世界中的特定示例：存在各种不同的实现，用于在单独的Kafka集群之间实时复制数据，包括MirrorMaker 1（属于Apache Kafka项目的一部分），MirrorMaker 2（属于Apache Kafka项目的一部分） ，Confluent Replicator（由Confluent构建，仅作为Confluent平台或Confluent Cloud的一部分提供），uReplicator（由Uber开源），Mirus（由Salesforce开源），Brooklin（由LinkedIn开源）。
实际上，如果您不想自己维护和改进代码，则只有两个选项是合理的：MirrorMaker 2（全新，尚未成熟，但从中长期来看是一个不错的选择）和Confluent Replicator（已在Windows 2000中进行了实战测试）许多关键任务部署，但不是开源的）。所有其他选项也都起作用。但是谁来维护项目呢？谁解决错误和安全性问题？如果您在生产中遇到问题，该给谁打电话？关键任务部署在生产中的部署不同于评估和试用开源项目。
误解3：“ Pulsar在单个解决方案中提供消息队列和事件流”？
部分地。
消息队列用于点对点通信。它们提供了异步通信协议，这意味着消息的发送者和接收者不需要同时与消息队列进行交互。d
Pulsar仅对 消息队列提供有限的支持，而对事件流仅提供有限的支持。如果要在这两个领域中竞争，它还有很长的路要走，原因有二：
1）Pulsar仅对消息队列提供有限的支持，因为它错过了流行的消息传递功能，例如消息XA事务，路由，消息过滤等，这些功能通常与诸如IBM MQ，RabbitMQ和ActiveMQ的消息传递系统一起使用。Pulsar对消息传递系统的“适配器”同样受到限制。尽管它们在纸上看起来不错，但在实践中用处不大。
2）Pulsar仅对事件流提供有限的支持。例如，它不支持精确的一次交付和处理语义，这实际上使它在大多数用例中都失去了资格–例如，您永远不会使用Pulsar实施付款处理系统，因为它可能导致重复付款或丢失付款。它还缺乏执行具有连接，聚合，开窗，容错状态管理和基于事件时间的处理等功能的流处理的功能。Pulsar的“主题”功能也与Kafka的功能不同，并且受BookKeeper的影响，因为它在2008年被构思和设计为Hadoop HDFS名称节点的预写日志，只考虑了短暂的数据存储。
旁注：与消息传递同级一样，Pulsar的“ Kafka适配器”也受到类似的限制。尽管在纸面上看起来不错，但由于它仅支持Kafka功能的一小部分，因此在实践中用处不大。
像Pulsar一样，Kafka仅对 消息排队提供有限的支持。
在Kafka中，可以使用不同的解决方法来实现“真实排队”行为。如果您要使用单独的消息队列而不是共享的Kafka主题，请执行以下操作：
安全？=>使用Kafka的ACL（以及可选工具，例如Confluent基于角色的访问控制，也称为RBAC）。
语义（即单独的应用程序）？=>使用Kafka的消费者群体。
负载均衡？=>使用Kafka的分区。
我通常会问客户他们到底想对消息队列做什么。通常，Kafka为用例提供了开箱即用的解决方案，这些用例只需要用新的术语考虑解决方案。另外，需要消息队列的高吞吐量用例的数量相对较少。
在解释了Pulsar和Kafka用于消息传递的所有这些变通办法和局限性之后，我们要弄清楚：Kafka和Pulsar均未提供“真正的消息传递解决方案”。
如果您真的需要一个消息传递解决方案，是否应该为消息传递问题更好地选择RabbitMQ或NATS之类的“真实消息传递框架”？
对此没有“是或否”的答案。我看到许多客户用Kafka替换了现有的消息传递系统（如IBM MQ）（出于可伸缩性和成本方面的考虑）。了解选项，权衡取舍，并进行评估以最好的方式解决您的问题……
误解4：“Pulsar提供流处理”？
错误的。
或公平地说：这取决于您对流处理的定义。仅仅是基本功能还是成熟的流处理？
我通常用一句话将流处理解释为来自不同数据源的事件的连续消耗，处理和聚合。实时。规模化。并且，当然，以容错的方式，包括（尤其是）任何有状态的处理操作。
Pulsar使用其Pulsar Functions接口仅提供用于流处理的基本功能。这适用于简单的回调，但是它并不是真正的流处理产品，就像您通过Kafka Streams或ksqlDB获得的那样，用于构建包括状态信息，滑动窗口和其他流处理概念的流应用程序。用例存在于每个行业。例如，请访问Kafka Streams网站，以获取《纽约时报》，Pinterest，Trivago，Zalando等的示例。
使用Pulsar进行流分析的示例通常将Pulsar与另一个“适当的”流处理框架（例如Apache Spark或Apache Flink）结合使用，这当然意味着您现在需要操作更多的分布式基础架构，并了解它们的复杂交互。
误解5：“ Pulsar提供像Kafka一样的一次语义(EOS)”？
错误的。
Pulsar提供了重复数据删除功能，可确保一条消息不会两次存储在Pulsar代理中，但是没有什么可以阻止使用者多次读取此消息。对于输入和输出均来自Pulsar的任何形式的流处理用例，这都是不够的。
另外，与Kafka的Transactions功能不同，不可能准确地将提交到流处理器中记录的状态的消息绑定在一起。
自Kafka 0.11（三年前发布）以来，就可以使用精确一次语义（EOS），并且已在许多生产部署中使用。Kafka的EOS支持整个Kafka生态系统，包括Kafka Connect，Kafka Streams，ksqlDB以及Java，C，C ++，Go或Python之类的客户端。Kafka Summit讨论了Kafka的EOS功能，包括幻灯片和视频录制，包括对每个人的精彩介绍。
误解六：“ Pulsar的表现远胜过Kafka的表现”？
错误的。
我不喜欢性能和吞吐量的大多数“基准”。基准几乎总是针对特定的问题而制定的（无论是由供应商，独立顾问还是由研究人员进行实施）。
例如，GIGAOM发布了一个基准测试，用于比较Kafka与Pulsar的延迟和性能。但是此基准测试通过设置Kafka配置'flush.messages = 1'（迫使每个请求引起fsync），迫使它在每条消息上与磁盘同步，从而故意降低了Kafka的速度。该基准测试还迫使Kafka消费者同步确认，而Pulsar消费者异步确认。毫不奇怪，此基准设置使Pulsar成为看似明确的“赢家”。但是此基准没有提及或解释设置和测量中的这种显着配置差异。这就是某些人所说的苹果与橘子的比较。
Pulsar的体系结构实际上需要更高的网络利用率（由于Pulsar经纪人层充当BookKeeper书本的代理人）和I O的两倍（因为BookKeeper将数据写入到预写日志以及主要部分中） ）。
Confluent也做了一些基准测试。更多的苹果到苹果的比较。毫不奇怪，结果是不同的。但是，您真的应该关心软件供应商的这些基准测试吗？
考虑一下您的性能要求。如有必要，请与Kafka和Pulsar进行概念验证（POC）。我敢打赌，在99％的方案中，两种方案都将显示出适合您的用例的性能。 不要相信别人自以为是的基准！无论如何，您的用例都会有不同的要求和特征，通常，性能只是许多评估维度之一。
误解7：“Pulsar比Kafka更易于操作”？
错误的。
如果您不使用其他工具，则Kafka和Pulsar都将难以操作。
Kafka包括两个分布式系统：Kafka本身和Apache ZooKeeper。
但是：Pulsar包括三个分布式系统和附加的存储技术：Pulsar，ZooKeeper和Apache BookKeeper。像Pulsar一样，BookKeeper也使用ZooKeeper。最后，RocksDB用于某些存储任务。这意味着与Kafka相比，Pulsar在理解，调整和调整方面的复杂度要高得多。此外，Pulsar还具有比Kafka更多的配置参数。
Kafka坚定地朝相反的方向发展，并正在删除ZooKeeper （请参阅KIP-500），以使您只有一个分布式系统可以部署，操作，扩展和监视：
ZooKeeper是Kafka最大的可扩展性瓶颈，并带来运营挑战—对于Kafka而言确实如此，但对Pulsar而言更是如此！
客户的关键问题之一是如何在关键任务部署中大规模运行ZooKeeper。因此，我非常期待Kafka的简化体系结构，在该体系结构中，您将仅部署Kafka经纪人。这也建立了统一的安全模型，因为ZooKeeper的安全性不再需要单独配置。这是一个巨大的好处，特别是对于大型组织和受监管的行业。合规和信息安全部门将感谢您提供的这种简化的体系结构。
操作不仅仅是架构！
Kafka的文档记录明显更好，拥有庞大的专家社区，并且提供了一系列支持工具，使操作变得更加容易。
此外，本地和在线Kafka培训还有很多选择，包括在线课程，书籍，聚会和会议。不幸的是，您不会为Pulsar找到很多东西。
误解八：“三层架构胜于两层架构”？
这取决于。
就我个人而言，我怀疑Pulsar的三层体系结构（使用Pulsar经纪人，ZooKeeper和BookKeeper）对于大多数项目都是有利的。这是一个权衡！
Twitter在一年多前就描述了他们从BookKeeper + DistributedLog（后者与Pulsar非常相似，具有可比的体系结构和设计）的举动，理由是Kafka的单层体系结构的优势（例如成本效率和更好的性能）超过了分离存储和服务的两层体系结构。
与Pulsar一样，DistributedLog建立在BookKeeper之上，并通过类似于Pulsar的体系结构和概念（例如，使用解耦的存储和服务层）添加了类似于流的功能。DistributedLog最初是一个独立的项目，但最终成为BookKeeper的子项目，尽管如今它似乎不再被积极开发（在过去的12个月中只有很少的提交）。的 主要原因Twitter的引切换到Kafka是：（1）显著的成本节省和性能提升;（2）Kafka的庞大的社区和通过。例如，他们得出结论：“对于单个消费者使用案例，我们节省了68％的资源，对于具有多个消费者的扇出案例，我们节省了75％的资源。”
三层体系结构可用于构建可扩展的基础结构，这有很多好处。但是额外的一层还可以使网络利用率提高（至少）33％，并且必须另外在两层中缓存Pulsar的代理中保存的数据以达到同等的性能，并且还必须两次写入磁盘，因为Bookkeeper的存储格式不是基于日志。
在运行大多数Kafka部署的云上，最好的后备存储层实际上不是BookKeeper之类的利基技术，而是AWS S3或GCP GCS等经过广泛使用和经过考验的对象存储。
由AWS S3和GCP GCS等支持的Confluent Platform中的分层存储可提供相同的好处，而无需Pulsar的BookKeeper额外层，以及由此架构导致的额外网络传输成本和延迟。Confluent花费了两年的时间来构建和发布适用于Kafka的分层存储，包括对您的关键任务数据的全球24/7支持。分层存储尚不适用于开放源代码Apache Kafka，但Confluent正在KIP-405上与Kafka社区的其他成员（包括一些主要的技术公司，如Uber）合作，以在Kafka上添加具有不同存储选项的Tiered Storage。
两种体系结构总有优缺点。我个人认为95％的项目不需要复杂的三层架构。在有意义的地方，还要增加外部，具有价格效益的存储的优势。您应该关心24/7服务级别协议（SLA），可伸缩性以及整个过程。以及与您的生态系统以及安全性，管理工具和支持的集成。如果您的需求需要三层体系结构，那么就顺其自然吧！
误区三：“ Pulsar的缓存层和存储层更适合滞后的消费者”？
错误的。
落后的使用者的主要问题是他们耗尽了页面缓存，即最近的消息已经被缓存。从较旧的段读取将替换这些段，从而降低消费者从日志开头读取数据的性能。
在这方面，Pulsar的体系结构实际上更糟。它在缓存刷新方面仍然存在相同的问题，但是现在读取必须进行额外的网络跳跃+和IO，而不仅仅是读取本地媒体。
误解9：“Kafka的规模不如Pulsar”？
错误的。
这是Pulsar社区的主要论据之一。正如我之前所说，这始终取决于所选的基准。例如，我已经看到了使用等效计算资源进行的测试，其中Kafka在高吞吐量下的性能明显优于Pulsar 。这是“ Pulsar vs. Kafka基准”，其中Kafka比Pulsar快得多：
ZooKeeper是Kafka最大的可扩展性瓶颈，并带来运营挑战—对于Kafka而言确实如此，但对Pulsar而言更是如此！
客户的关键问题之一是如何在关键任务部署中大规模运行ZooKeeper。因此，我非常期待Kafka的简化体系结构，在该体系结构中，您将仅部署Kafka经纪人。这也建立了统一的安全模型，因为ZooKeeper的安全性不再需要单独配置。这是一个巨大的好处，特别是对于大型组织和受监管的行业。合规和信息安全部门将感谢您提供的这种简化的体系结构。
操作不仅仅是架构！
Kafka的文档记录明显更好，拥有庞大的专家社区，并且提供了一系列支持工具，使操作变得更加容易。
此外，本地和在线Kafka培训还有很多选择，包括在线课程，书籍，聚会和会议。不幸的是，您不会为Pulsar找到很多东西。
误解八：“三层架构胜于两层架构”？
这取决于。
就我个人而言，我怀疑Pulsar的三层体系结构（使用Pulsar经纪人，ZooKeeper和BookKeeper）对于大多数项目都是有利的。这是一个权衡！
Twitter在一年多前就描述了他们从BookKeeper + DistributedLog（后者与Pulsar非常相似，具有可比的体系结构和设计）的举动，理由是Kafka的单层体系结构的优势（例如成本效率和更好的性能）超过了分离存储和服务的两层体系结构。
与Pulsar一样，DistributedLog建立在BookKeeper之上，并通过类似于Pulsar的体系结构和概念（例如，使用解耦的存储和服务层）添加了类似于流的功能。DistributedLog最初是一个独立的项目，但最终成为BookKeeper的子项目，尽管如今它似乎不再被积极开发（在过去的12个月中只有很少的提交）。的 主要原因Twitter的引切换到Kafka是：（1）显著的成本节省和性能提升;（2）Kafka的庞大的社区和通过。例如，他们得出结论：“对于单个消费者使用案例，我们节省了68％的资源，对于具有多个消费者的扇出案例，我们节省了75％的资源。”
三层体系结构可用于构建可扩展的基础结构，这有很多好处。但是额外的一层还可以使网络利用率提高（至少）33％，并且必须另外在两层中缓存Pulsar的代理中保存的数据以达到同等的性能，并且还必须两次写入磁盘，因为Bookkeeper的存储格式不是基于日志。
在运行大多数Kafka部署的云上，最好的后备存储层实际上不是BookKeeper之类的利基技术，而是AWS S3或GCP GCS等经过广泛使用和经过考验的对象存储。
由AWS S3和GCP GCS等支持的Confluent Platform中的分层存储可提供相同的好处，而无需Pulsar的BookKeeper额外层，以及由此架构导致的额外网络传输成本和延迟。Confluent花费了两年的时间来构建和发布适用于Kafka的分层存储，包括对您的关键任务数据的全球24/7支持。分层存储尚不适用于开放源代码Apache Kafka，但Confluent正在KIP-405上与Kafka社区的其他成员（包括一些主要的技术公司，如Uber）合作，以在Kafka上添加具有不同存储选项的Tiered Storage。
两种体系结构总有优缺点。我个人认为95％的项目不需要复杂的三层架构。在有意义的地方，还要增加外部，具有价格效益的存储的优势。您应该关心24/7服务级别协议（SLA），可伸缩性以及整个过程。以及与您的生态系统以及安全性，管理工具和支持的集成。如果您的需求需要三层体系结构，那么就顺其自然吧！
误区三：“ Pulsar的缓存层和存储层更适合滞后的消费者”？
错误的。
落后的使用者的主要问题是他们耗尽了页面缓存，即最近的消息已经被缓存。从较旧的段读取将替换这些段，从而降低消费者从日志开头读取数据的性能。
在这方面，Pulsar的体系结构实际上更糟。它在缓存刷新方面仍然存在相同的问题，但是现在读取必须进行额外的网络跳跃+和IO，而不仅仅是读取本地媒体。
误解9：“Kafka的规模不如Pulsar”？
错误的。
这是Pulsar社区的主要论据之一。正如我之前所说，这始终取决于所选的基准。例如，我已经看到了使用等效计算资源进行的测试，其中Kafka在高吞吐量下的性能明显优于Pulsar 。这是“ Pulsar vs. Kafka基准”，其中Kafka比Pulsar快得多：
对于大多数用例，可伸缩性不是问题。您可以轻松地将Kafka扩展到每秒处理几GB的数据，如在“在Confluent Cloud中将Apache Kafka扩展到每秒10+ GB ”的演示中看到的那样.
坦白地说，不到1％的用户应该完全担心此讨论。如果您有诸如Netflix（每天处理PB级）或LinkedIn（每天处理数万亿条消息）之类的要求，那么让我们讨论一下并讨论这种部署的最佳架构，硬件和配置。对于其他任何人，请不要担心。
误区三：“ Kafka当前的方法意味着每个集群只能存储约50万个分区”？
真的。
对于拥有数十万个Kafka主题和分区的大规模部署，当今的Kafka尚不是最佳的体系结构。
但是：Pulsar也不允许无限的规模。它只是有不同的限制。
Kafka的分区限制是由Zookeeper施加的。通过KIP-500中的工作从Kafka中删除Zookeeper，可以消除此上限。
附带说明：
正确的架构设计对于成功至关重要！
我所见过的大多数困扰Kafka分区数量和可伸缩性的客户是因为他们以错误的方式设计了自己的体系结构和应用程序（如果使用Pulsar，他们会遇到同样的问题）！
Kafka是事件流平台，而不是下一个IBM MQ。如果尝试使用Kafka重新创建自己喜欢的MQ解决方案和体系结构，则可能会失败。我看到一些客户在这里失败，然后在我们的帮助下通过重新架构他们的设置来成功。
如果您正确设计用例并了解Kafka的基本概念，那么很有可能您甚至在今天就使用Kafka对ZooKeeper的分区号和可伸缩性都不会有任何问题。客户的体验是任何技术（例如Kafka）的共同主题，该技术引入了远远超过以前的技术水平和范式（最主要的例子是公司在开始将用例转移到其他方面时所面临的采用障碍。云端）。
亚神话：“ Pulsar支持几乎无限数量的分区”？
错误的。
BookKeeper具有与Kafka相同的“每分类帐每个文件1个”限制，但是在一个分区中有多个分类帐。Pulsar的代理层将分区分为多个束，但它的存储层Bookkeeper将数据存储在段中，每个分区有很多段。
与Kafka一样，这些段的元数据存储在Zookeeper中，这对可存储的总数施加了限制。Kafka消除了这种依赖关系，从而使它可以进一步扩展。我真的很期待KIP-500在2020年底之前得到实施。“ Apache Kafka不需要守护者：消除Apache ZooKeeper依赖性”将带您逐步了解实施细节和计划的时间表。
误解：“创建Kafka主题时需要定义Kafka缩放比例”？
部分正确。
如果需要更大的可伸缩性，则可以对Kafka主题进行过度分区（即，为主题配置的分区数量比用例最初需要的分区多；请参阅Apache Kafka中的流和表：主题，分区和存储基础知识），或者，如果将来有扩展需求，则可以将它们重新配置为使用更多分区。这不是完美的，但这是分布式事件流如何工作的结果（以及为什么它的扩展性要比IBM MQ等传统消息传递系统好得多）。
提供了创建主题的最佳实践以及在生产过程中更改主题配置的过程。所以不用担心！
但是：Pulsar主题也有此限制！
写入吞吐量基于Pulsar主题中分配的分区数量，其分配方式与Kafka主题中分配的分区完全相同，因此出于完全相同的原因，必须对Pulsar主题进行超额配置。这是因为，对于每个分区，一次（分区中可能有多个分类账）中只有一个分类账是可写的。同样，增加分区数会动态影响消息顺序，就像在Kafka中一样（即消息顺序丢失）。
Kafka和Pulsar都变得疯狂。这几乎适用于所有用例！
如果您需要更大的扩展规模，我认为不使用ZooKeeper的实现是最佳选择。因此，KIP-500是我在社区和Confluent的客户群中最期待的Kafka更改。
误解10：“ Pulsar立即从计算机故障中恢复，但Kafka必须重新加载数据”？
是真也是假的。
杀死Pulsar代理确实是无缝的，但是（与Kafka代理相反），Pulsar代理不存储任何数据，而只是位于实际存储层（即BookKeeper）前面的代理。因此，强调Pulsar经纪人的失败很容易解决就引起了市场的分散注意力，因为实际上，人们必须谈论BookKeeper节点（“ bookie”）发生故障时会发生什么。
杀死并重启BookKeeper赌徒需要对数据进行的重新分配，和kafka一致。这是分布式系统的本质，具有复制和分区等概念。
弹性kafka已经在这里！
弹性很重要。Confluent的创始人Jay Kreps最近在博客上发表了有关该主题的文章：Confluent Cloud中的Elastic Apache Kafka集群。在像Confluent Cloud这样的SaaS云服务中，最终用户完全不必关心机器故障。预期24/7的正常运行时间，并应通过99.xx SLA予以保证。基于消费的定价（即按需付费）意味着您根本不必担心代理管理，调整代理节点大小，扩展或缩小集群等问题。
自我管理的Kafka群集也需要类似的功能。Kafka的分层存储之所以巨大，是因为大多数数据不再存储在代理中，从而几乎可以从故障中立即进行恢复。结合诸如Self-Balancing Kafka（第3季度将提供的Confluent功能，并在上面的链接博客文章中进行了讨论）之类的工具，用户完全不必担心其自我管理集群的弹性。
不幸的是，如果您正在寻找Pulsar的这种现代产品，则没有可用的产品。
神话11：“ Pulsar比Kafka具有更好的集群间（Geo）复制”？
错误的。
每个分布式系统必须解决分布式计算中的CAP定理和仲裁之类的问题。法定人数是为了允许在分布式系统中执行操作而必须获得的分布式事务的最小投票数。实现了基于仲裁的技术，以在分布式系统中强制执行一致的操作。
Kafka需要ZooKeeper来解决仲裁问题。即使在删除KIP-500和ZooKeeper之后，现实世界中的通用物理定律仍然相同：在美国东部，中部和西部甚至全球范围内部署分布式系统仍然存在延迟问题。那是因为光速虽然很高，但确实有极限。
解决此问题的方法有很多种，其中包括Apache Kafka的MirrorMaker 2，Confluent的Replicator或Confluent的Multi-Region-Clusters等实时复制工具。查阅“用于分布式，混合，边缘和全局Apache Kafka部署的架构模式”以了解各种不同的部署选项和最佳实践：
没有提供全局复制和零停机+零数据丢失的单一模式或实现！对于最关键的应用程序，即使整个数据中心或云区域出现故障，Confluent的Multi-Region-Clusters都允许RTO = 0和RPO = 0（即零停机时间和零数据丢失），并具有自动灾难恢复和客户端故障转移功能。
在这里，Pulsar的体系结构比“基本的” Pulsar部署需要更多的复杂性。这是因为，对于地理复制，Pulsar需要附加的“全局” Zookeeper群集，这使Pulsar不适合进行长距离地理分布。有一种解决方法，但是围绕CAP定理和物理学的问题并没有解决。
无论您使用的是Kafka还是Pulsar，您都需要经过考验的设计才能在全球部署中与物理定律相抵触！
误解12：“ Pulsar与Kafka的界面和API兼容”？
部分正确。
Pulsar提供了一个非常基本的实现，仅与Kafka v2.0协议的一小部分兼容。
Pulsar具有用于Kafka协议基本部分的转换器。
因此，尽管所谓的“ Kafka兼容性”在纸面上听起来不错，但您不应该为将您正在运行的Kafka基础架构迁移到Pulsar而认真考虑这一点吗？我怀疑有人会冒险...
在其他示例中，例如更成熟的Azure Event Hubs服务，我们看到了“ Kafka兼容性”声明。查看其Kafka API的限制因素，并感到惊讶！不支持Kafka的核心功能，例如事务（因此是一次语义），压缩或日志压缩。
由于不是Kafka的内幕，因此，当您将现有的Kafka应用程序与这样的“兼容”设置连接时，还会期望进一步的差异和意外行为。无论是Azure事件中心，Pulsar还是任何其他包装。
Kafka vs Pulsar – 全面比较
最后几节探讨了我们在许多其他博客文章中发现的各种技术神话。我想我为这些讨论带来了一些清晰度。
现在，让我们不要忘记浏览Kafka和Pulsar的技术细节。选择技术时，非功能性方面同样重要。
我将在以下内容中介绍三个关键方面：市场吸引力，企业支持和云产品。
Apache Kafka和Apache Pulsar的市场牵引力
回顾过去五年的Google趋势证实了我的个人经历，与Apache Kafka相比，我对Apache Pulsar的兴趣非常有限：
当您查看Stack Overflow和类似的平台，支持厂商的数量和规模，开放的生态系统（工具集成，诸如Spring Kafka之类的包装框架）以及技术趋势的相似特征时，情况看起来非常相似。
职位空缺是采用技术的另一个很好的指标。Pulsar的职位空缺并不多，意味着没有多少公司在使用它。在您最喜欢的工作搜索引擎中搜索。如果您在全球范围内进行搜索，您会发现Pulsar的职位空缺少于100个，而Kafka的职位空缺数千个。另外，大多数显示Pulsar的人都说“寻找关于Kafka，Pulsar，Kinesis或类似技术的经验”。
在大多数情况下，这些特性与下一个项目的成功更为相关，而不是细微的技术差异。的主要目标是解决业务问题，不是吗？
因此，在缺乏采用的情况下，为什么Pulsar完全参与对话？原因之一是独立咨询公司，研究分析师和博客作者（包括我在内）需要谈论新的前沿技术，以保持其受众的兴趣……老实说，这是一个很好的故事。
企业对Kafka和Pulsar的支持
有针对Kafka和Pulsar的企业支持！
但是，情况并非您所期望的。您可以致电以下供应商并要求举行会议，以讨论在Pulsar旅程中共同努力的潜在后续步骤：
Streamlio（现已由Splunk收购），Apache Pulsar背后的前公司。Splunk尚未宣布未来的Pulsar战略，以支持在自己的基于Pulsar的项目中工作的人们。Splunk以其广泛采用的分析平台而闻名。那就是他们的核心业务（2019年约为$ 1.8B）。人们唯一抱怨Splunk的是定价。Splunk是Kafka的主要用户，现在将Pulsar集成到他们的Splunk数据流处理器（DSP）中。Splunk会跳上开源浪潮来支持您的下一个独立的Pulsar项目是非常令人怀疑的（当然，更广泛的DSP可能会问世）。未来将向我们展示……
由Apache Pulsar的原始开发人员之一创建的StreamNative提供基于Pulsar的事件流平台。在撰写本文时（2020年6月），StreamNative在LinkedIn上拥有13（！）名员工。我不确定这是否适合您的规模，以支持您在2020年进行的下一个关键任务部署，但他们确实提供了。
泰科于2019年12月宣布对Pulsar的支持。最近几年，他们的核心战略从集成转向了分析。TIBCO的中间件客户正在大量迁移。他们的中间件团队必须做出一些绝望的战略决策：即使对项目的贡献和经验为零，也要支持其他平台。您是对的，这可能是个神话。但是，嘿，事实是TIBCO也对Kafka也做同样的事情。这是一个不错的琐事：TIBCO在Windows上为您提供Kafka和ZooKeeper！其他人没有做的事情–因为其他人知道这是不稳定的，并且始终会产生不一致之处。但是，嘿，TIBCO现在可以通过Kafka和Pulsar为您提供支持。如果一个供应商允许您同时使用这两个框架，为什么还要评估这两个框架？即使在Windows上；.exe下载和。
支持Kafka的供应商数量每季度都在增加！
同时，Kafka拥有不可思议的巨大市场采用率。最好的证明是最大的软件供应商提供围绕它的支持和工具时。IBM，Oracle，Amazon，Microsoft和许多其他软件公司都支持Kafka并建立集成功能并围绕它开发自己的产品。
对我来说，最新的“唤醒电话”是在旧金山举行的Oracle OpenWorld 2019上，在那儿，我参加了来自Oracle产品经理GoldenGate的路线图会议（Oracle著名的功能强大但又非常昂贵的CDC工具）。大部分讨论都集中在开放GoldenGate使其成为所有内容的数据集成平台上。一半的讨论是关于事件流，Kafka以及GoldenGate将如何在两个方向上与不同的数据库/数据湖和Kafka集成。
针对Kafka和Pulsar的完全托管的云产品
让我们看一下可用于Kafka和Pulsar的云产品。
Apache Pulsar提供了云服务。它有一个非常创新的名称：
kafka式（Kafkaesque）。
别开玩笑了。检查链接…[更新：〜6月17日，他们将服务重新命名：KAFKAESQUE现在是KESQUE-可能他们意识到这个名称是多么令人尴尬。]
也许您还检查了Apache Kafka的各种云产品，以找出哪种产品更适合您：
Confluent Cloud（SaaS）是一项完全托管的服务，为Apache Kafka及其生态系统（例如，架构注册表，Kafka Connect连接器和用于流处理的ksqlDB）提供基于消耗的定价，24/7 SLA和弹性，无服务器特性。
Amazon MSK（PaaS）设置了ZooKeeper和Kafka Brokers，以便最终用户可以操作它，修复错误，进行滚动升级等。每个人都应该意识到的一个重要事实：AWS在其99.95 SLA和支持中排除了Kafka问题！
Azure事件中心（SaaS）提供了一个Kafka终结点（具有专有的实现），可以与Kafka应用程序进行交互。它具有很好的可扩展性和性能。因为它不是真正的Kafka，而是一个仿真，所以它错过了Kafka的几个核心功能，例如一次语义，日志压缩和压缩。更不用说Kafka Connect和Kafka Streams等周边功能
蓝色巨人（IBM）和红色巨人（Oracle）提供了有关Kafka及其API的云产品。我不知道是否有人在使用它们以及它们有多好。我从来没有见过他们在野外。
很多较小的参与者，例如Aiven，CloudKarafka，Instaclustr等。
如您所见，当前的云产品相对清楚地表明了Kafka和Pulsar在市场上的采用情况。
结论– Apache Kafka还是Apache Pulsar？
TL; DR：就大规模使用案例和建立社区而言，Pulsar距离Kafka的成熟水平还有很长的路要走。
您还应该质疑Pulsar是否实际上更好。
如果您要采用纯开源方式，请评估Kafka和Pulsar。找出最适合您的。在您的评估中，包括技术功能集，成熟度，供应商，开发人员社区和其他相关因素。哪一种最适合您的情况？
如果您需要的企业解决方案不仅仅需要涵盖这两个开源系统所提供的功能，那么Kafka是唯一的选择：从各种供应商之一中选择基于Kafka的产品或合适的云产品。不幸的是，Pulsar没有为今天和可预见的未来做好准备。
