摘要：Pulsar作为一个云原生的分布式音讯流平台，越来越频繁地呈现在人们的视线中，大有代替Kafka江湖位置的趋势。

本文分享自华为云社区《MRS Pulsar：下一代分布式音讯流平台全新公布！》，作者： Lothar。

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/doc...

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

MRS上的Pulsar

MRS已公布Pulsar的POC版本，客户能够一键式部署Pulsar服务，包含Broker和Bookie角色。反对在Web UI上批改Pulsar配置、启停、监控。

此外MRS还默认集成了KoP。KoP是Pulsar社区开源的一个插件，运行在Pulsar上，用以兼容Kafka协定。应用时，Kafka客户端能够批改连贯地址后间接切换到Pulsar集群上，而不须要批改业务对Kafka客户端的依赖。

在MRS Pulsar的商用版本正在布局中，咱们将摸索Pulsar在云上应用的更多可能，进一步施展Pulsar存算拆散的劣势，降低成本，晋升资源利用率，为客户发明更多价值，敬请期待。

点击关注，第一工夫理解华为云陈腐技术~