Pulsar vs Kafka?一文掌握高性能消息组件 Pulsar 基础知识
什么是 Pulsar?
Apache Pulsar 是 Apache 软件基金会顶级项目,是下一代云原生分布式消息流平台,集消息、存储、轻量化函数式计算为一体,采用计算与存储分离架构设计,支持多租户、持久化存储、多机房跨区域数据复制,具有强一致性、高吞吐以及低延时的高可扩展流数据存储特性。
Pulsar 的关键特性
Pulsar 的单个实例原生支持多个集群,可跨机房在集群间无缝地完成消息复制。
极低的发布延迟和端到端延迟。
可无缝扩展到超过 一百万 个 topic。
简单的客户端 API,支持 Java、Go、Python 和 C++。
支持多种 topic 订阅模式(独占订阅、共享订阅、故障转移订阅)。
通过 Apache BookKeeper 提供的持久化消息存储机制保证消息传递 。
由轻量级的 serverless 计算框架 Pulsar Functions 实现流原生的数据处理。
基于 Pulsar Functions 的 serverless connector 框架 Pulsar IO 使得数据更易移入、移出 Apache Pulsar。
分层式存储可在数据陈旧时,将数据从热存储卸载到冷/长期存储(如 S3、GCS)中。
Pulsar vs Kafka
下方链接为 Pulsar 与 Kafka 详细对比报告,可自行下载查看
https://streamnative.io/en/blog/tech/2020-07-08-pulsar-vs-kafka-part-1
https://streamnative.io/zh/blog/tech/2020-07-22-pulsar-vs-kafka-part-2
性能与可用性
基准测试(StreamNative)
数据来源
https://mp.weixin.qq.com/s/UZJTOEpzX8foUJv9XMJxOw
https://streamnative.io/en/blog/tech/2020-11-09-benchmark-pulsar-kafka-performance
https://streamnative.io/whitepaper/benchmark-pulsar-vs-kafka
吞吐量(Throughput)
在与 Kafka 的持久性保证相同的情况下,Pulsar 可达到 605 MB/s 的发布和端到端吞吐量(与 Kafka 相同)以及 3.5 GB/s 的 catch-up read 吞吐量(比 Kafka 高 3.5 倍)。Pulsar 的吞吐量不会因分区数量的增加和持久性级别的改变而受到影响,而 Kafka 的吞吐量会因分区数量或持久性级别的改变而受到严重影响。
延迟性(Latency)
在不同的测试实例(包括不同订阅数量、不同主题数量和不同持久性保证)中,Pulsar 的延迟显著低于 Kafka。Pulsar P99 延迟在 5 到 15 毫秒之间。Kafka P99 延迟可能长达数秒,并且会因主题数量、订阅数量和不同持久性保证而受到巨大影响。
功能性
多语言客户端(C/C++、Python、Java、Go ...)
管理工具(Pulsar Manager vs Kafka Manager)
内置流处理 Built-In Stream Processing(Pulsar Function vs Kafka Streams)
Rich Integrations (Pulsar Connectors)
Exactly-Once Processing
日志压缩
多租户(Pulsar)
安全管理(Pulsar)
架构设计
Pulsar 采用存储和计算分离的软件架构。在消息领域,Pulsar 是第一个将存储计算分离云原生架构落地的开源项目。由于在 Broker 层不存储任何数据,这种架构为用户带来了更高的可用性、更灵活的扩容和管理、避免数据的 reblance 和 catch-up。
在 Apache Pulsar 的分层架构中,服务层 Broker 和存储层 BookKeeper 的每个节点都是对等的。Broker 仅仅负责消息的服务支持,不存储数据。这为服务层和存储层提供了瞬时的节点扩展和无缝的失效恢复。
持久化存储(Persistent storage)
Pulsar 使用 BookKeeper 分布式日志存储数据库作为存储组件,在底层使用日志作为存储模型。
Pulsar 将所有未确认消息(即未处理消息)存储在 BookKeeper 中的多个“bookie”服务器上。
BookKeeper 通过 Quorum Vote 的方式来实现数据的一致性,跟 Master/Slave 模式不同,BookKeeper 中每个节点也是对等的,对一份数据会并发地同时写入指定数目的存储节点。
一个 Topic 实际上是一个 ledgers 流。Ledger 本身就是一个日志。所以一系列的子日志(Ledgers)组成了一个父日志(Topic)。
Ledgers 追加到一个 Topic,条目(消息或者一组消息)追加到 Ledgers。Ledger 一旦关闭是不可变的。Ledger 作为最小的删除单元,也就是说我们不能删除单个条目而是去删除整个 Ledger。
Ledgers 本身也被分解为多个 Fragment。Fragment 是 BookKeeper 集群中最小的分布单元。
每个 Ledger(由一个或多个 Fragment 组成)可以跨多个 BookKeeper 节点(Bookies)进行复制,以实现数据容灾和提升读取性能。每个 Fragment 都在一组不同的 Bookies 中复制(存在足够的 Bookies)。
conf/bookkeeper.conf
conf/broker.conf
元数据存储(Metadata storage)
Pulsar 和 BookKeeper 都使用 Apache Zookeeper 来存储元数据和监控节点健康状况。
更多福利
云智慧已开源集轻量级、聚合型、智能运维为一体的综合运维管理平台 OMP(Operation Management Platform) ,具备 纳管、部署、监控、巡检、自愈、备份、恢复 等功能,可为用户提供便捷的运维能力和业务管理,在提高运维人员等工作效率的同时,极大提升了业务的连续性和安全性。点击下方地址链接,欢迎大家给 OMP 点赞送 star,了解更多相关内容~
GitHub 地址: https://github.com/CloudWise-OpenSource/OMP
Gitee 地址:https://gitee.com/CloudWise/OMP
微信扫描识别下方二维码,备注【OMP】加入 AIOps 社区运维管理平台 OMP 开发者交流群,与更多行业大佬一起交流学习~
评论