关于pulsar:Pulsar-与-Kafka-全方位对比上篇功能性能用例

越来越多的音讯平台开始采纳实时流技术，这促成了 Pulsar 的应用与倒退。在 2020 年，Pulsar 的受关注度与使用量都有了显著减少。从《财产》百强企业到有前瞻性的初创团队，但凡开发音讯平台和事件流应用程序的公司都对 Pulsar 放弃关注，始终在激励着 Pulsar 的倒退，并且，围绕 Pulsar 我的项目的生态也有了迅猛发展，近期多家媒体也在对此争相报道。

最近的新闻和博客文章都在主观地介绍 Pulsar，读者能够清晰地理解 Pulsar 的性能及用例。Verizon Media、Iterable、Nutanix、Overstock.com 等公司最近也公布了 Pulsar 的用例，并分享了对于如何通过 Pulsar 实现商业指标的一系列想法。

然而，媒体的信息并非齐全实在精确。此外，Pulsar 社区的小伙伴也向咱们发出请求，心愿咱们针对近期 Confluent 博客发表的《Kafka、Pulsar 和 RabbitMQ 比照》技术文章做出回应。很庆幸，Pulsar 可能倒退如此迅速，并成为一项变革性的技术，咱们也很想借此机会深刻探索 Pulsar 的性能。

本文将深刻介绍 Pulsar 技术、社区及生态的相干信息，主观、全面地展现事件流的整体状况。本系列文章共有两篇，本文为上篇，次要比照 Pulsar 和 Kafka 在性能、架构和个性方面的区别。下篇次要介绍 Pulsar 的用例、反对与社区等。

留神
因为 Kafka 的可用文档更为全面，熟知的人也更多，本文会重点介绍目前 Pulsar 绝对根底和文档中波及不多的内容。

详情

组件

Pulsar 由 3 个次要组件组成：broker、Apache BookKeeper 和 Apache ZooKeeper。Broker 是无状态服务，客户端须要连贯到 broker 进行外围消息传递。而 BookKeeper 和 ZooKeeper 是有状态服务。BookKeeper 节点（bookie）存储音讯与游标，ZooKeeper 则只用于为 broker 和 bookie 存储元数据。另外，BookKeeper 应用 RocksDB 作为内嵌数据库，用于存储外部索引，但 RocksDB 的治理不独立于 BookKeeper。

Kafka 采纳单片架构模型，将服务与存储相结合，而 Pulsar 则采纳了 多层架构，能够在独自的层内进行治理。Pulsar 中的 broker 在一个层上进行计算，而 bookie 则在另一个层上治理有状态存储。

Pulsar 的多层架构看起来仿佛比 Kafka 的单片架构更为简单，但理论状况却没这么简略。架构设计须要权衡利弊，BookKeeper 使得 Pulsar 更具可伸缩性、操作累赘更低、速度更快，性能也更统一。在后文中，咱们会就以上几点进行具体探讨。

存储架构

Pulsar 的多层架构影响到了其存储数据的形式。Pulsar 将 topic 分区划分为分片，而后将这些分片存储在 Apache BookKeeper 的存储节点上，以进步性能、可伸缩性和可用性。

Pulsar 的有限分布式日志以分片为核心，借助扩大日志存储（通过 Apache BookKeeper）实现，内置分层存储反对，因而分片能够平均地散布在存储节点上。因为与任一给定 topic 相干的数据都不会与特定存储节点进行捆绑，因而很容易替换存储节点或缩扩容。另外，集群中最小或最慢的节点也不会成为存储或带宽的短板。

Pulsar 的架构 无分区，也没有重均衡，保障了及时可伸缩性和高可用性。这两个重要个性使 Pulsar 尤其实用于构建与要害工作相干的服务，如金融用例的计费平台，电子商务和零售商的交易解决零碎，金融机构的实时危险控制系统等。

通过利用性能弱小的 Netty 架构，数据从 producers 到 broker，再到 bookie 的转移都是零拷贝，都不会生成正本。这一个性对所有流用例都十分敌对，因为数据间接通过网络或磁盘进行传输，没有任何性能损失。

音讯生产

Pulsar 的生产模型采纳了 流拉取 的形式。流拉取是长轮询的改进版，不仅实现了单个调用和申请之间的零期待，还能够提供双向音讯流。通过流拉取模型，Pulsar 实现了比所有现有长轮询音讯零碎（如 Kafka）都低的端到端提早。

应用简略

运维简略

在评估特定技术的操作简便性时，不仅要思考初始设置，还要思考长期保护和可伸缩性。须要思考以下几项：

• 要跟上业务增长的速度，扩大集群的操作是否迅速便捷？
• 集群是否对多租户（对应于多团队、多用户）开箱可用？
• 运维工作（如替换硬件）是否会影响业务的可用性与可靠性？
• 是否能够轻松复制数据以实现数据的天文冗余或不同的拜访模式？

长期应用 Kafka 的用户会发现在运维 Kafka 时上述问题都不容易答复。其中少数工作都须要 Kafka 之外的其余工具，如用于治理集群再均衡的 cruise control，以及用于复制需要的 Kafka mirror-maker。

因为 Kafka 很难在团队之间共享，很多机构开发了用于反对和治理多个不同集群的工具。这些工具对胜利大规模应用 Kafka 至关重要，但同时也减少了 Kafka 的复杂性。最适宜用来治理 Kafka 集群的工具都是商业软件，不开源。那这就不意外了，囿于 Kafka 简单的治理和运维，许多企业转而采买 Confluent 的商业服务。

相比之下，Pulsar 的指标是简化运维和可扩大。依据 Pulsar 的性能，咱们对以上问题作出如下答复：

• 要跟上业务增长的速度，扩大集群的操作是否迅速便捷？

Pulsar 的主动负载平衡性能能够主动并立刻应用集群中新加的计算和存储能力。这使得 broker 之间能够迁徙 topic 来均衡负载，新 bookie 节点能够立刻承受新数据分片的写入流量，而无需手动从新均衡或治理 broker。

• 集群是否对多租户（对应于多团队、多用户）开箱可用？

Pulsar 采纳分层架构，租户和命名空间可能与机构或团队造成良好的逻辑映射，Pulsar 通过这种雷同的机构反对繁难 ACL、配额、自主服务管制，甚至也反对资源隔离，从而容许集群使用者轻松治理共享集群。

• 运维工作（如替换硬件）是否会影响业务的可用性与可靠性？

替换 Pulsar 的无状态 broker 操作简略，无需放心数据失落。Bookie 节点会主动复制全副未复制的数据分片，而且用于解除和替换节点的工具为内置工具，很容易实现自动化。

• 是否能够轻松复制数据以实现数据的天文冗余或不同的拜访模式？

Pulsar 具备内置的复制性能，可用于无缝逾越天文区域同步数据或复制数据到其余集群，以实现其余性能（如灾备、剖析等）。

相比于 Kafka，Pulsar 的个性为流数据的事实问题提供了更残缺的解决方案。从这个角度看，Pulsar 领有 更欠缺的外围功能集，应用简略，因此容许使用者和开发者专一于业务的外围需要。

文档与学习

因为 Pulsar 是一项比 Kafka 更新的技术，其生态系统还不够欠缺，文档和培训资源也仍在补充中。然而，这也正是在过来一年半的工夫里，Pulsar 的次要倒退方向。以下为一些次要成绩：

• Pulsar Summit Virtual Conference 2020，Pulsar 的首次寰球峰会，来自超过 25 个机构的演讲者共计进行了 36 次分享，注册参会者超过 600 人。
• 2020 年已原创 50+ 视频及培训版块。
• Pulsar 每周直播及互动教程。
• 业内当先讲师进行专业培训。
• 与策略商业伙伴每月举办一次网络研讨会。
• 公布涂鸦、OVHCloud、腾讯、Yahoo!Japan 等用例的白皮书。

更多对于 Pulsar 文档和培训的内容，参阅 StreamNative 的 Resources 网站。

企业反对

Kafka 和 Pulsar 都能够提供企业级反对。多个大型供应商（包含 Confluent）为 Kafka 提供了企业级反对。StreamNative 为 Pulsar 提供了企业级反对，但 StreamNative 仍在起步倒退阶段。StreamNative 为企业提供全面托管的 Pulsar 云端服务及 Pulsar 企业级反对服务。

StreamNative 团队在音讯和事件流方面经验丰富，成长迅速。StreamNative 由 Pulsar 和 BookKeeper 核心成员创立。在 StreamNative 团队的帮忙下，Pulsar 生态系统在短短几年工夫里突飞猛进，如失去了策略合作伙伴的反对，这种反对将会进一步促成 Pulsar 的倒退，以满足大量用例的需要（这部分内容将在下篇文章中具体介绍）。

Pulsar 最近的重大进展如 KoP（即 Kafka-on-Pulsar），由 OVHCloud 和 StreamNative 于 2020 年 3 月推出。通过向现有 Pulsar 集群增加 KoP 协定处理程序，用户能够将现有的 Kafka 应用程序和服务迁徙到 Pulsar，而无需批改代码。在 2020 年 6 月，中国移动与 StreamNative 发表推出另一重要产品 —— AoP（即 AMQP on Pulsar）。AoP 使得 RabbitMQ 应用程序能够利用 Pulsar 的个性，如应用 Apache BookKeeper 和分层存储反对有限事件流存储等。这部分内容会在下篇中具体介绍。

生态集成

随着 Pulsar 用户迅速减少，Pulsar 社区曾经倒退成为大型、高度参加、用户全球化的社区。Pulsar 生态系统中周边工具插件数量迅速增长，沉闷的 Pulsar 社区起到了极其重要的推动作用。在过来的六个月里，Pulsar 生态系统中官网反对的 connector 数量急剧增长。

为了进一步反对 Pulsar 社区的倒退，StreamNative 不久前推出了 StreamNative Hub。StreamNative Hub 反对用户查找、下载集成。这一平台将有助于减速 Pulsar connector 和插件生态系统的倒退。

Pulsar 社区也始终在踊跃地与其余社区密切合作，以整合单方的我的项目。例如，Pulsar 社区与 Flink 社区始终在共同开发 Pulsar-Flink Connector（FLIP-72 的一部分）。通过 Pulsar-Spark Connector，用户能够应用 Apache Spark 解决 Apache Pulsar 中的处理事件。SkyWalking Pulsar 插件集成了 Apache SkyWalking 和 Apache Pulsar，容许用户通过 SkyWalking 追踪音讯。除此之外，Pulsar 社区还有很多正在进行中的集成我的项目。

多元客户端库

Pulsar 目前官网反对 7 种语言，而 Kafka 只反对 1 种语言。Confluent 博客指出 Kafka 目前反对 22 种语言，然而，官网客户端并不能反对这么多种语言，而且一些语言曾经不再保护。依据最新统计，Apache Kafka 官网客户端只反对 1 种语言，而 Apache Pulsar 官网客户端反对 7 种语言。

• Java
• C
• C++
• Python
• Go
• .NET
• Node

Pulsar 还反对由 Pulsar 社区开发的诸多客户端，如：

• Rust
• Scala
• Ruby
• Erlang

性能与可用性

吞吐量、提早与容量

Pulsar 和 Kafka 都被宽泛用于多个企业用例，也各有劣势，都能通过数量基本相同的硬件解决大流量。局部用户误以为 Pulsar 应用了更多的组件，因而须要更多的服务器来实现与 Kafka 相匹敌的性能。尽管这种想法确实实用于一些特定硬件配置，但 在少数等同资源配置中，Pulsar 劣势更加显著，能够以雷同的资源实现更多性能。

举例来说，Splunk 最近分享了他们抉择 Pulsar 而非 Kafka 的起因，其中提到因为分层架构，Pulsar 帮忙他们将老本升高了 1.5 – 2 倍，提早升高了 5 – 50 倍，经营老本升高 2 -3 倍（幻灯片第 34 页）。Splunk 团队发现这是因为 Pulsar 能够更好地利用磁盘 IO，升高 CPU 利用率，同时更好地管制内存。

腾讯等公司抉择 Pulsar 在很大水平上是因为 Pulsar 的性能属性。在腾讯计费平台白皮书中提到，腾讯计费平台领有百万级用户，治理约 300 亿第三方托管账户，目前正在应用 Pulsar 解决每天数亿美元的交易。思考到 Pulsar 可预测的低提早、更强的一致性和持久性保障，腾讯抉择了 Pulsar 而非 Kafka。

有序性保障

Apache Pulsar 反对四种不同订阅模式。单个应用程序的订阅模式由排序和生产可扩展性需要决定。以下为这四种订阅模式及相干的排序保障：

• 独占 和灾备 订阅模式都在分区级别反对强排序保障，反对跨 consumer 并行生产同一 topic 上的音讯。
• 共享 订阅模式反对将 consumer 的数量扩大至超过分区的数量，因而这种模式非常适合 worker 队列用例。
• 键共享 订阅模式联合了其余订阅模式的长处，反对将 consumer 的数量扩大至超过分区的数量，也反对键级别的强排序保障。

更多对于 Pulsar 订阅模式和相干排序保障的信息，参阅订阅。

个性

内置流解决

Pulsar 和 Kafka 对于内置流解决的指标不尽相同。针对较为简单的流解决需要，Pulsar 集成了 Flink 和 Spark 这两个成熟的流解决框架，并开发了 Pulsar Functions 来解决轻量级计算。Kafka 则开发并应用 Kafka Streams 这一成熟的流解决引擎。

然而，应用 Kafka Streams 要更简单一些。用户须要弄清楚应用 KStreams 应用程序的场景及办法。并且，对于大多数轻量级计算用例来说，KStreams 过于简单。

另外，Pulsar Functions 轻松实现了轻量级计算用例，并容许用户创立简单的解决逻辑，而无需部署独自的邻近零碎。Pulsar Functions 还反对原生语言和易于应用的 API。用户不用学习简单的 API 就能够编写事件流应用程序。

一份最近提交的 Pulsar 改良计划（Pulsar Improvement Proposal，PIP）中介绍了 Function Mesh。Function Mesh 是无服务器架构的事件流框架，联合应用多个 Pulsar Functions 以便于构建简单的事件流应用程序。

Exactly-Once 解决

目前，Pulsar 通过 broker 端去重反对 exactly-once producer。这个重大项目正在开发中，敬请期待！

Pulsar 自 PIP-31 起反对事务型音讯流，目前仍在开发中。这一个性进步了 Pulsar 的消息传递语义和解决保障。在交易型流中，每条音讯只会写入一次、解决一次，即使 broker 或 Function 实例呈现故障，也不会呈现数据反复或数据失落。交易型音讯不仅简化了应用 Pulsar 或 Pulsar Functions 向应用程序写入的操作，还扩大了 Pulsar 反对的用例的范畴。对于 Pulsar 这一个性的开发进展顺利，将会在 Pulsar 2.7.0 版本中公布，预计公布工夫 2020 年 9 月。

Topic（日志）压缩

Pulsar 旨在反对用户生产数据。应用程序能够须要抉择应用 原始 数据或 压缩 数据。Pulsar 通过这种按需抉择的形式，容许未压缩数据通过保留策略管制无限度增长，但仍容许通过周期性压缩生成最新的实物化视图。内置的分层存储个性反对 Pulsar 从 BookKeeper 卸载未压缩数据到云存储中，因此升高长期存储事件的老本。

相比于 Pulsar，Kafka 不反对用户应用原始数据。并且，在数据压缩后，Kafka 会立刻删除原始数据。

用例

事件流

雅虎最后开发 Pulsar 将其同时用作公布 / 订阅音讯的平台（又称云音讯）。然而，Pulsar 当初不仅是一个音讯平台，还是 对立的音讯和事件流平台。Pulsar 引入了一系列工具，作为平台的一部分，为构建事件流应用程序提供必要的根底。Pulsar 反对以下事件流性能：

• 有限事件流存储 反对通过向外扩大日志存储（通过 Apache BookKeeper）大规模存储事件，并且 Pulsar 内置的分层存储反对高质量、低成本的零碎，如 S3、HDFS 等。
• 对立的公布 / 订阅音讯模型 反对用户轻易地向应用程序中增加音讯。这一模型能够依据流量和用户需要进行伸缩。
• 协定解决 框架、Pulsar 与 Kafka 的协定兼容性（通过 Kafka-on-Pulsar，KoP），以及 AMQP（通过 AMQP-on-Pulsar）反对应用程序应用任一现有协定在任一地位生产和生产事件。
• Pulsar IO 提供了一组与大型生态系统集成的 connector，容许用户从内部零碎获取数据，而无需编写代码。
• Pulsar 与 Flink 的集成 反对全面的事件处理。
• Pulsar Functions 提供了一个轻量级无服务器框架来解决达到的事件。
• Pulsar 与 Presto 的集成（Pulsar SQL）反对数据专家和用户应用 ANSI 兼容的 SQL 来剖析数据和解决业务。

音讯路由

通过 Pulsar IO、Pulsar Functions、Pulsar Protocol Handler，Pulsar 具备全面路由的性能。Pulsar 的路由性能包含基于内容的路由、音讯转换，和音讯裁减。

和 Kafka 相比，Pulsar 的路由能力更持重。Pulsar 为 connector 和 Functions 提供了更灵便的部署模型。繁难的部署能够在 broker 中运行。另外，部署也能够在专用的节点池中运行（相似于 Kafka Streams），节点池反对大规模扩大。Pulsar 还与 Kubernetes 原生集成。另外，能够将 Pulsar 配置为以 pod 的模式来调度 Functions 和 connector 的工作负载，充分利用 Kubernetes 的弹性。

音讯队列

如前文所述，Pulsar 最后的开发目标是作为对立的音讯公布 / 订阅平台。Pulsar 团队深刻理解了现有开源音讯零碎的优缺点，并基于团队的教训设计了 Pulsar 的对立音讯模型。Pulsar 音讯 API 同时反对 队列 和流。不仅能够实现 worker 队列，以轮询的形式将音讯发送给相互竞争的 consumer（通过共享订阅），还能够通过两种形式反对事件流：一是基于分区（通过灾备订阅）中音讯的程序；二是基于键范畴（通过键共享订阅）中音讯的程序。用户能够在同一组数据上构建音讯应用程序和事件流应用程序，而无需复制数据到不同数据系统。

另外，Pulsar 社区还在尝试使 Apache Pulsar 能够原生反对不同的音讯协定（如 AoP、KoP），以扩大 Pulsar 的性能。

结语

Pulsar 社区始终在一直发展壮大，Pulsar 技术的倒退和用例数量的减少曾经造成良性循环，Pulsar 生态也在壮大。

Pulsar 具备许多劣势，因而可能在对立的音讯和事件流平台怀才不遇，并成为更多人的抉择。相比于 Kafka，Pulsar 更具备弹性，在运维和扩大上更为简略。

大多数新技术的推出和被采纳都须要花一些工夫，但 Pulsar 不仅提供了全套解决方案，保护成本低，还能够在装置后立刻应用。Pulsar 涵盖了构建事件流应用程序所需的全副根底，并集成了许多内置个性（包含多种工具）。Pulsar 的工具也能够立刻应用，不须要独自装置。

StreamNative 始终致力于在开发 Pulsar 新性能的同时，增强现有性能，同时促成社区倒退。在实现 2020 年年度工作的过程中，目前所有停顿顺利，咱们期待在九月公布 Pulsar 2.7.0。

敬请关注本系列文章下篇：Pulsar 的应用、用例、反对与社区。

特地致谢

感激为本文撰写公布提供帮忙的多位 Pulsar 社区成员：Jerry Peng、Jesse Anderson、Joe Francis、Matteo Merli、Sanjeev Kulkarni、Addison Higham 等。