共计 2838 个字符，预计需要花费 8 分钟才能阅读完成。
摘要：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 存算拆散的劣势，降低成本，晋升资源利用率，为客户发明更多价值，敬请期待。
点击关注，第一工夫理解华为云陈腐技术~
