Apache Pulsar:下一代分布式消息流平台
Pulsar的前世今生
Apache Pulsar是一个发布-订阅消息系统,使用计算与存储分离的云原生架构。Pulsar 2018年9月成为ASF顶级项目,近两年,随着社区不断发展和诸多企业的应用和贡献,Pulsar作为一个云原生的分布式消息流平台,越来越频繁地出现在人们的视野中,大有替代Kafka江湖地位的趋势。
Pulsar和Kafka的对比
Pulsar和Kafka架构上最大的不同是,Kafka由Broker进行消息的收发和持久化,数据存储在本地文件系统,由Broker统一管理。这也意味着数据和消息处理是耦合的。
Kafka官网描述道:Kafka重度依赖文件系统,用于存储或缓存消息。当Broker接收到消息时,会将消息追加写到本地磁盘上。这一架构决定了Partition和Broker的对应关系是相对固定的,只有在partition reassign时才会发生数据迁移。Partition的Leader在数据副本分布节点上产生,用于处理生产消费请求。
而Pulsar采用了计算存储分离架构,这也是Pulsar被称作云原生平台的主要原因。Pulsar依赖Apache BookKeeper管理持久化数据,Apache BookKeeper是可扩展、可容错、低延迟的日志存储服务,能够保证在强持久性下的低延迟读写。
*引自Pulsar官网介绍:https://pulsar.apache.org/docs/en/concepts-architecture-overview/
Broker接收请求后,数据实际分布式存储在BookKeeper服务中。在数据的物理存储模型中某个Topic或Partition的数据并不固定存储在某个Bookie实例上。
Pulsar将分布式日志划分为多个Segment,每个Segment对应BookKeeper中的一个Ledger。与Kafka将某一Partition的数据日志保存在某一固定目录下不同,Pulsar通过划分Segment的方式,可以将同一topic或partition分布到不同的Bookie上。
Pulsar的优势特性
灵活扩展
相信很多使用Kafka的客户都有类似的经历:
- 磁盘空间不足,只能调整数据TTL,或扩容机器后向新的Broker中迁移Partition
- Topic或Partition间数据分配不均匀,节点之间或磁盘之间使用不均衡,有的磁盘已经满了,而有的磁盘还有很多空间
- Broker机器故障,需要将数据迁移到其他节点后下电维修
Pulsar的存算分离架构天然地避免了这些问题。Pulsar Broker本身是无状态的,当某个Broker故障时,另一个Broker可以立即接管对应的Topic而不需要迁移数据。BookKeeper分布式日志保证了存储节点间的数据均衡,不会因某一个Partitoin或Topic数据过多而导致IO集中在某一节点上。
当集群需要扩容时,Broker可以立即感知到新加入集群的Bookie,并将新写入的数据存储到新添加的Bookie中。
多租户
Kafka社区在KIP-37正在讨论加入NameSpace以实现多租户特性,而Pulsar已实现这一功能。在企业中,消息队列服务通常会被多个团队使用,在使用Kafka时,有时需要为每个团队维护一个Kafka集群。Pulsar可以配置多个租户,每个租户可以有多个NameSpace,管理员可以对NameSpace进行访问控制、配额管理。
更灵活的订阅模式
Kafka对消息的划分分为两层:对于属于同一个Group的KafkaConsumer,其获取到的消息是互斥的,即某一条消息只能被Group中的一个Consumer处理;对于不同的Group,某一条消息将同时被两个Group处理,消息是共享的。
而Pulsar提供了更灵活的订阅模式:
- 独占式:
在任意时间,Topic中的数据只能被Group中的一个Consumer消费,不允许其他Consumer获取消息
- 主备式:
多个Consumer同时消费同一个Topic时,只有一个Consumer被选为主Consumer,其他Consumer则成为备Consumer。当主Consumer故障时,发生主备倒换,备Consumer中的一个将升主,并继续消息的消费。
- 共享式:
与Kafka类似,使用共享模式,消息将循环分发给不同的Consumer,当某个Consumer故障时,消息将被重新分配给其他Consumer。
分层存储
Pulsar另一个很有吸引里的特性是,流式数据可以转冷并存储在更廉价的存储介质上。通常为了保证性能,流式处理系统配备高性能的SSD。对于Kafka来说,所有需要保留的消息都必须驻留在昂贵的SSD上。有些时候,数据写入一段时间后已不在会被使用,但仍需保留一段时间存档。Pulsar支持将这种冷数据转储到离线存储系统中,BookKeeper只需要保留一部分热数据,可以节省很多存储成本。该特性无疑是很有价值的,Kafka社区同样在进行设计(KIP-405),但目前还没有实现。
Pulsar的性能指标
Kafka和Pulsar社区都针对性能进行了对比测试。综合来看,由于Pulsar数据落盘时,会进行同步fsync,持久性要比Kafka更高,Pulsar社区对此作出修改后进行对比测试,部分测试结果如下:
*引自Pulsar社区性能测试报告
在100 Partition时,默认配置下pulsar的吞吐量距离Kafka差距明显,但当本地持久化等级设置为与Kafka相同时,吞吐量与Kafka基本持平。
*引自Pulsar社区性能测试报告
当Partition数增加到2000个时,Pulsar默认本地持久度的吞吐量基本与Kafka持平。
更多细节请移步SreamNative的benckmarking测试报告:benchmarking pulsar kafka a more accurate perspective on pulsar performance.pdf