本文作者为 jesse-anderson。内容由 StreamNative 翻译并整顿。
以三个理论应用场景为例，从 CTO 的视角登程，在技术等方面比照 Kafka 和 Pulsar。
浏览本文须要大概 8 分钟。

对于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。
GitHub 地址：http://github.com/apache/pulsar/

在评估新技术时，高层管理人员的视角通常与中层管理人员、架构师、数据工程师等有所不同。高层管理人员不仅要关注基准测试后果、产品反对的个性，还要从久远角度思考新技术的可靠性，新技术可能为企业带来哪些竞争劣势，以及是否能够缩短上市工夫、节约开销。

我是 Big Data Institute 的常务董事，技术评估是我的一项次要工作。咱们帮忙企业依据业务需要抉择并落地最合适的技术。咱们不与供应商单干，因而客户尤为看中咱们可能主观地评估不同的技术。

在本文中，我将从 CTO 的视角登程，比照 Apache Pulsar 和 Apache Kafka。只进行实践上的比照空洞有效，也不能帮忙咱们作出决策，理论用例才真正值得参考。所以，在本文中，我会通过一些常见的理论应用场景来比照 Pulsar 和 Kafka，即简略音讯应用场景、简单音讯应用场景和高级音讯应用场景。在这些理论应用场景下，Pulsar 和 Kafka 的体现可能帮忙咱们更好地了解二者的性能和劣势，进而作出决策。

简略音讯应用场景

假如有一个企业，之前从未应用过音讯零碎，当初须要通过一个简略的音讯零碎，将音讯从地位 A 发送到地位 B，但不须要复制音讯。

数据架构师团队在深入研究 Pulsar 和 Kafka 的业务案例后，得出如下论断：在这一应用场景中，Pulsar 和 Kafka 都没有绝对优势。并且，他们认为在短时间内，该应用场景根本不会产生扭转。

对于相似这样的简略音讯应用场景而言，我也同意 Pulsar 和 Kafka 都没有绝对优势。仅从技术角度登程，Pulsar 和 Kafka 这一回合打成平局，那么咱们只能思考老本。二者的经营老本、员工培训老本别离是多少？我打算依据 Kafka 或 Pulsar 的服务提供商的免费规范进行比照。比照开销时，选好服务提供商也能够在肯定水平上缩小经营老本和员工培训老本。Kafka 的云服务提供商，我参考了应用 Kafka API（Azure）的 Confluent Cloud、MSK（AWS）和 Event Hubs。Pulsar 的云服务提供商，我抉择 StreamNative Cloud。

比照后果

出于稳当思考，咱们决定抉择 Kafka API。目前，已有多种技术支持非 Kafka broker 应用 Kafka API 或传输协定。应用 Kafka API，非 Kafka broker 可通过增加新库反对 Kafka 的传输协定，保障对 Kafka API 的兼容性，从而最大化技术抉择的多样性。例如，能够通过批改 Kafka API 的实现从新编译或通过 Pulsar broker 解析 Kafka 的协定（KOP），将 Pulsar 用作 Kafka 的后端。

咱们在比照单位成本后，抉择了老本效益高的一方。Kafka API 能够保障后端品质，用户在后端之间的数据挪动不会受到影响，无效躲避危险。即便社区不沉闷，技术热度不高，咱们的应用也不会受到影响。

简单音讯应用场景

假如一个公司须要简单音讯零碎。因为须要解决世界各地的数据，必须反对跨地区复制。该企业始终在应用音讯零碎，因而对实时零碎的复杂性有肯定的理解，也发现了以后音讯零碎的不足之处。因而该企业对音讯零碎的要求是可能解决高级的消息传递和简单的音讯个性。

数据架构师团队和股东以及业务部门具体探讨了以后和将来需要。最初得出的论断是，Pulsar 和 Kafka 各有劣势。同时，他们认为随着工夫的推移，该应用场景和数据量都会有所增长。

在这种状况下，Pulsar 和 Kafka 难分输赢。要想作出正确决策，必须深入研究二者的应用场景。

跨地区复制

Kafka 既提供公有的（价格高）跨地区复制，也提供开源的（附加服务）跨地区复制解决方案。公有的跨地区复制解决方案为其内置个性，但价格昂扬。开源的解决方案（MirrorMaker）实际上就是数据复制，但因为不是其内置个性，会减少经营开销。

Pulsar 提供开源内置的跨地区复制个性，反对简单的复制策略。对于应用场景和数据量都在减少的企业而言，显然，反对内置跨地区复制策略的 Pulsar 完胜。

就跨地区复制而言，咱们抉择 Pulsar。

简单音讯

因为企业正在向新音讯平台迁徙，音讯零碎最好能够解决新应用场景。数据架构师团队始终在理解各个平台，尝试寻找最佳解决方案。在以后应用的音讯零碎中，一旦呈现处理错误，必须从新生成音讯，再手动重试，因而最好还能够引入音讯提早发送。另外，以后音讯零碎的 schema 施行性能也有待增强，各个团队抉择不同的 schema 实现时，团队单干的难度显著减少。

Kafka 没有内置死信队列个性，一旦音讯解决失败，必须手动解决，或批改代码重试。Kafka 也没有提早发送音讯的内置机制，提早发送音讯流程简单、工作量大。另外，Kafka 没有内置 schema 施行机制，导致云服务提供商别离提供了不同的 schema 解决方案。

Pulsar 内置死信队列个性，当音讯解决失败，收到否定 ack 时，Pulsar 能够主动重试，但次数无限。Pulsar 也反对提早发送音讯，能够设定延迟时间。对于 Pulsar 而言，schema 级别高，因而 Pulsar 有内置 schema 注册，Pulsar API 也原生反对 schema。

就简单音讯而言，咱们抉择 Pulsar。

高级消息传递

随着对架构的深刻理解，咱们发现为了确保平均分配资源，须要循环发送同一 topic 上的数据，并且须要通过排序确保音讯有序排列。

Kafka 不能散发音讯给指定的 consumer。当 consumer 接管到不属于它生产的音讯时，要保障这些音讯被正确生产，咱们只能从新发送这些音讯到额定的 topic 中，但这样会造成数据冗余，减少应用老本。因而，咱们须要能够制订路由规定发送给指定 consumer 的产品。

Pulsar broker 能够通过制订的路由规定，把一个 topic 的不同音讯依据路由规定发送到指定的 consumer 中。Pulsar broker 轻松实现了咱们的指标，无需任何额定工作。

就高级消息传递而言，咱们抉择 Pulsar。

部署和社区

为了全面比拟 Pulsar 和 Kafka，咱们还须要看一下二者的部署数量和社区详情。

从服务市场来看，Kafka 的提供商更多，销售和反对 Kafka 产品的团队也更多。Kafka 和 Pulsar 的开源社区都踊跃沉闷，但 Kafka 的社区规模更大。

从应用市场来看，Kafka 和 Pulsar 都已部署在大公司的大型生产环境中。在生产环境中部署 Kafka 的公司在数量上更胜一筹。

从用户数量来看，Kafka 的用户更多。然而，数据工程师团队认为，Kafka 的使用者能够轻松学习 Pulsar。

就服务反对和社区而言，咱们抉择 Kafka。但值得一提的是，Pulsar 社区正在迅速倒退。

比照后果

因为 Pulsar 和 Kafka 在这一应用场景中都有显著的优劣势，决策难度大大增加。

Pulsar 能够在社区和部署上奋起直追，Kafka 则能够致力丰盛产品个性。

在作出决策前，咱们先来总结一下，该企业在技术上最看重哪方面；在技术方面，咱们是否须要做最激进的抉择。依据以往的教训，新的开源技术会带来更多惊喜，因而咱们更偏向于抉择 Pulsar。

如果抉择 Kafka，咱们须要承当向业务赞助商坦诚“咱们无奈解决这一应用场景”的危险。甚至，即便领取大笔资金购买跨地区复制许可，也无奈保障顺利实现客户的需要。业务团队最终可能须要花大量工夫（甚至几个月）来编写、欠缺、测试他们的工作计划。

如果抉择 Pulsar，咱们能够通知业务赞助商“所有尽在把握中”。因为 Pulsar 的各项内置个性都曾经过测试，应用团队能够在短时间内实现部署。

在这种状况下，因为咱们不须要 Kafka API 的独有个性，所以咱们没有应用反对 Kafka 协定（KOP）的 Pulsar Broker，而是抉择 Pulsar API，因为 Pulsar API 反对所有咱们须要 Kafka API 提供的性能。

决策如下：抉择 Pulsar，能够优先解决业务申请，开发团队只专一编写代码，而不是解决其余问题。抉择 Pulsar 的同时，也关注 Pulsar 社区和提供商的动静。

如果采取激进决策抉择 Kafka，须要承受可能无奈实现某些应用场景的事实。对于类似的应用场景，咱们采取相应解决方案。调整我的项目工夫布局，减少履行预期解决方案的工夫。分割经营团队，确保能够接受执行预期解决方案的开销。

高级音讯应用场景

假如一个公司曾经在应用多种音讯和队列零碎。从经营、架构和开销的角度来看，咱们认为有必要迁徙到单个零碎。同时，咱们也心愿升高经营老本。

数据架构师团队在和股东以及业务部门具体探讨了以后和将来需要后，给出的论断是，Pulsar 和 Kafka 各有劣势。

队列和音讯

最大的难题是 RabbitMQ 零碎。咱们应用 RabbitMQ 发送太多音讯，RabbitMQ 曾经无奈满足需要。咱们调整了 RabbitMQ 的代码，将音讯缓冲在内存中，并持续创立新集群来解决负载。然而咱们须要的不是变通方法，而是一个可能解决大规模音讯的零碎。

数据架构师在钻研这一应用场景时，得出结论：新零碎必须能够同时解决音讯流模型和队列模型。咱们不仅须要持续应用 RabbitMQ 解决音讯，也须要更高级的音讯技术。

Kafka 善于消息传递，也能够解决大规模音讯流，然而无奈解决队列。开发团队能够尝试一些解决方案，但这样就不能实现应用单个零碎的预期指标。要解决队列应用场景，就同时须要 Kafka 集群和 RabbitMQ 集群。Kafka 集群更像一个缓冲区，能够无效避免 RabbitMQ 集群过载。然而 Kafka 不反对原生 RabbitMQ，咱们须要与提供商单干或本人编写代码，才能够实现在 Kafka 和 RabbitMQ 之间挪动数据。

Pulsar 能够在同一集群中解决队列和音讯，还反对扩大集群。Pulsar 能够将所有音讯流模型和队列模型的应用场景整合到一个集群中。用户能够持续应用 RabbitMQ 代码，Pulsar 反对 RabbitMQ 连接器，或者在 broker 中应用 StreamNative 开发的 AoP（AMQP 协定解决插件），该插件已取得 Apache 许可。

如果不想持续应用 RabbitMQ 代码，则能够应用 Pulsar API。Pulsar API 具备和 RabbitMQ 雷同的队列性能。用户须要对代码进行相应批改，工作量取决于原代码的构造和细节，批改代码后，还须要对代码进行评估测试。

就队列模型和音讯流模型而言，咱们抉择 Pulsar。

高级保留

数据架构师剖析了数据应用状况，发现 99.99% 的数据在首次应用后就未被读取。然而，他们决定采取激进策略，保留音讯一周。尽管决定存储数据一周，但咱们不心愿减少太多经营老本。分层存储能够保留数据到本地，而后卸载其余数据到 S3，升高长期保留数据的老本。

Kafka 团队正在开发分层存储，但 Kafka 目前还不反对这一个性。一些服务商提供公有分层存储，但咱们不确定是否能够间接用于生产环境中。

分层存储是 Pulsar 的原生个性，能够间接用于生产环境。目前已有多个企业在生产环境中部署该个性。

就分层存储而言，咱们抉择 Pulsar。Kafka 正在全力开发分层存储，这一个性的重要性显而易见。

路由 Topic

因为咱们应用多个 topic 来合成数据，咱们期待新零碎能够创立大量 topic。数据架构师认为，咱们起初须要 10 万个 topic，随着工夫的推移，这个数字将会涨到 50 万。

Kafka 集群反对创立的分区数量无限且每个 topic 至多须要一个分区。Kafka 正在减少可反对 topic 的数量，但新个性尚未公布。另外，Kafka 没有命名空间和多租户，因而无奈基于 topic 对资源进行分片，十万个 topic 须要存储在同一个命名空间中。

一些企业确实在应用 Kafka 集群存储甚至更多的 topic，同时进行了资源分片。但他们放弃应用繁多集群，同时还须要为此领取费用。

Pulsar 反对存储数百万个 topic，这一性能早已公布并投入生产环境。Pulsar 反对命名空间和多租户，用户能够为每个 topic 设置资源配额，进而节约开销。

就 topic 而言，咱们抉择 Pulsar。

路由

因为咱们假如该企业已经应用 RabbitMQ，在设计上，个别通过 broker 路由机制把 topic 上的数据转发到不同的 topic 中。例如，有一个用于存储世界范畴数据的 topic，而 RabbitMQ broker 把它解决成以国家为单位的 topic。

数据架构师团队深入研究了如何在音讯零碎中应用繁多 topic 存储世界范畴的数据。他们发现当接收数据量增大时，上游 consumer 无奈持续解决数据。对每个上游零碎进行反序列化、查看数据，再抛弃数据的流程繁冗，且费时费力。

Kafka 将所有数据存储在繁多 topic 中，然而，当 consumer 须要过滤的数据量减少或集群过载时，这个办法不可行。咱们通常须要进行程度缩放，减少 consumer 数量，才能够读取全局 topic 并做进一步解决。用户只能抉择：编写自定义 consumer / producer，编写 Kafka Streams 程序，或应用专有 KSQL。

Pulsar 反对应用 Pulsar Functions 或自定义 consumer / producer 进行路由，因而能够先读取全局 topic，再将数据保留到以国家为单位的特定 topic 上。应用独立 topic，consumer 能够按需订阅 topic，只接管相干音讯。

就路由而言，咱们抉择 Pulsar。

最终决策

工夫是影响最终决策的次要起因。咱们是否有工夫让 Kafka 赶上 Pulsar？咱们是否有工夫让数据工程师来实现 Kafka 的解决方案？期待会让公司错失良机，延缓减少新的应用场景，影响业务倒退。

最终决策：咱们抉择 Pulsar。

工夫短缺状况下的决策：提早应用新架构。给 Kafka 半年工夫，看 Kafka 是否能够在性能上赶超 Pulsar。如果能够，咱们将在生产环境中测试这些新个性，评估稳定性。如果 Kafka 不能让人眼前一亮，咱们依然会抉择 Pulsar。

结语

本文波及的三个应用场景都是我在理论工作中遇到的，心愿本文给出的解决方案能够为您提供参考，帮忙您依据具体应用场景进行技术评估。

相干浏览

Pulsar 与 Kafka 全方位比照（上篇）：性能、性能、用例

Pulsar 与 Kafka 全方位比照（下篇）：案例、个性、社区

Pulsar 和 Kafka 基准测试：Pulsar 性能精准解析（完整版）

援用链接

[1] Kafka API（Azure）: _https://docs.microsoft.com/en…
[2] Confluent Cloud: _https://www.confluent.io/conf…
[3] MSK（AWS）: _https://aws.amazon.com/cn/msk/_
[4] Event Hubs: _https://azure.microsoft.com/e…
[5] StreamNative Cloud: _https://streamnative.io/zh/cl…
[6] AoP（AMQP 协定解决插件）: _https://github.com/streamnati…

Pulsar 2020 用户考察流动行将截止，没有填写的小伙伴不要错失为 Pulsar 提倡议的良机???? 赶快扫描下方二维码填写，有机会取得新版 Pulsar 社区周边哦！

点击「下方链接」，填写问卷、抽取周边吧！
https://docs.qq.com/form/page…