越来越多的消息平台开始采用实时流技术，这促进了 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。
Kfka 采用单片架构模型，将服务与存储相结合，而 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 等。
来源：oschina
链接：https://my.oschina.net/apachepulsar/blog/4492281