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

ApachePulsar

于 2020-08-13 11:52:27 发布

阅读量9.1k

点赞数 6

CC 4.0 BY-SA版权

分类专栏： Pulsar干货 Pulsar介绍文章标签：大数据

本文链接：https://blog.csdn.net/zhaijia03/article/details/107976374

本文是Pulsar与Kafka全方位对比的上篇，主要探讨两者的功能、性能和用例。Pulsar采用多层架构，通过Apache BookKeeper和ZooKeeper实现高可伸缩性和低延迟。其流拉取消费模型提供低延迟，多租户支持简化运维。Pulsar的自动负载均衡、内置复制和扩展性优于Kafka，适合关键任务服务。然而，Pulsar的文档和培训资源仍待完善，但社区和生态系统正在快速发展。

越来越多的消息平台开始采用实时流技术，这促进了 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 相关的数据都不会与特定存储节点进行捆绑，因此很容易替换存储节点或缩扩容。另外，集群中最小或最慢的节点也不会成为存储或带宽的短板。