这篇文章主要介绍“Pulsar与Kafka有哪些区别”，在日常操作中，相信很多人在Pulsar与Kafka有哪些区别问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Pulsar与Kafka有哪些区别”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
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 以便于构建复杂的事件流应用程序。
目前，Pulsar 通过 broker 端去重支持 exactly-once producer。这个重大项目正在开发中，敬请期待！
Pulsar 自 PIP-31 起支持事务型消息流，目前仍在开发中。这一特性提高了 Pulsar 的消息传递语义和处理保证。在交易型流中，每条消息只会写入一次、处理一次，即便 broker 或 Function 实例出现故障，也不会出现数据重复或数据丢失。交易型消息不仅简化了使用 Pulsar 或 Pulsar Functions 向应用程序写入的操作，还扩展了 Pulsar 支持的用例的范围。关于 Pulsar 这一特性的开发进展顺利，将会在 Pulsar 2.7.0 版本中发布，预计发布时间 2020 年 9 月。
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与Kafka有哪些区别”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
