引言

提起成熟的消息队列或消息引擎，毋庸置疑，大多数人的第一反应一定是 Kafka。

Kafka 能够彻底满足海量数据场景下高吞吐、高并发需求，在短短几年内，已经被阿里、腾讯、百度、字节跳动、Netflix、Twitter 等超一线大厂视为技术核心——可以说，Kafka 是目前大数据 Spark 实时流处理的标配。

Kafka 的优势

Kafka 具有高吞吐量、低延迟、容错、持久性、可伸缩性，尤其是广为人知的高吞吐量，Kafka 每秒大约可以生产约 25 万消息（50 MB），每秒处理 55 万消息（110 MB）！Kafka 还有一个巨大的优势就是容错，它具备一个固有功能，可以自行应对集群中的节点故障。

Kafka 的不足

在运维和实践过程中，Kafka 却也始终存在着一些棘手的问题。例如：

• 扩展性较差，剥离 Broker 意味着必须复制 topic 分区和副本，效率很低；

• 缺乏一致性，一旦 API 发生变化很有可能出现问题；

• 存储成本非常高，几乎没有人用Kafka长时间存储数据；

• 没有与租户完全隔离的本地多租户，需要自行配置解决方案

Pulsar 背景介绍

俯瞰技术生态，有没有一个平台，能够既拥有 Kafka 的优势，又规避它的缺陷，同时还融合了 MQ 的一系列特性呢？

有，那就是 Pulsar。

Apache Pulsar 是 Apache 软件基金会顶级项目，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体。该系统源于 Yahoo，最初在 Yahoo 内部开发和部署，支持 Yahoo 应用服务平台 140 万个主题，日处理超过 1000 亿条消息。

Pulsar 于 2016 年由 Yahoo 开源并捐赠给 Apache 软件基金会进行孵化，2018 年成为 Apache 软件基金会顶级项目。

Pulsar 作为下一代云原生分布式消息流平台，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐以及低延时的高可扩展流数据存储特性，内置诸多其他系统商业版本才有的特性，是云原生时代解决实时消息流数据传输、存储和计算的最佳解决方案。

目前，Apache Pulsar 已经应用部署在国内外众多大型互联网公司和传统行业公司，案例分布在人工智能、金融、电信运营商、直播与短视频、物联网、零售与电子商务、在线教育等多个行业，如美国有线电视网络巨头 Comcast、Yahoo！、腾讯、中国电信、中国移动、BIGO、VIPKID 等。

目前 Apache Pulsar 项目原生核心贡献者已组成创业公司 StreamNative，进一步为 Apache Pulsar 提供更好的企业级服务支持与生态建设。

Plusar 是什么

"Pulsar is a distributed pub-sub messaging platform with a very flexible messaging model and an intuitive client API."

Pulsar 是 pub-sub（发布者/订阅者）模式的分布式消息平台，拥有灵活的消息模型和直观的客户端 API。

核心概念

Topic（主题）

Topic 是Pulsar的核心概念，表示一个“channel”，Producer 可以写入数据，Consumer 从中消费数据（与 Kafka 类似）。

Topic 名称的 URL 类似如下的结构：

{persistent|non-persistent}://tenant/namespace/topic

• persistent|non-persistent：表示数据是否持久化（Pulsar支持消息持久化和非持久化两种模式）
• Tenant：表示为租户
• Namespace：一般聚合一系列相关的Topic，一个租户下可以有多个Namespace

Tenant（租户）和Namespace（名称空间）关系

上图中 Property 即为租户，每个租户下可以有多个 Namespace，每个 Namespace 下有多个 Topic。

Namespace 是 Pulsar 中的操作单元，包括Topic是配置在Namespace级别的，包括多地域复制，消息过期策略等都是配置在Namespace上的。

订阅模型

Pulsar 提供了灵活的消息模型，支持三种订阅类型：

• Exclusive subscription：排他的，只能有一个Consumer，接收一个Topic所有的消息

• Shared subscription：共享的，可以同时存在多个Consumer，每个Consumer处理Topic中一部消息（Shared模型是不保证消息顺序的，Consumer数量可以超过分区的数量）

• Failover subscription：Failover模式，同一时刻只有一个有效的Consumer，其余的Consumer作为备用节点，在Master Consumer不可用后进行替代（看起来适用于数据量小，且解决单点故障的场景）

分区（Partition）

为了解决吞吐等问题，Pulsar和Kafka一样，采用了分区（Partition）的机制。

Pulsar提供了一些策略来处理消息到Partition的路由（MessageRouter）：

• Single partitioning：Producer随机选择一个Partition并将所有消息写入到这个分区
• Round robin partitioning ：采用Round robin的方式，轮训所有分区进行消息写入
• Hash partitioning：这种模式每条消息有一个Key，Producer根据消息的Key的哈希值进行分区的选择（Key相同的消息可以保证顺序）。
• Custom partitioning：用户自定义路由策略

不同于别的MQ系统，Pulsar允许Consumer的数量超过分区的数量（对于RocketMQ，超过分区数的Consumer会分配不到分区而“空跑”）。

在Shared subscription的订阅模式下，Consumer数量可以大于分区的数量，每个Consumer处理每个Partition中的一部分消息，不保证消息的顺序。

持久化

Pulsar通过 BookKeeper 来存储消息，保证消息不会丢失（BookKeeper：A scalable, fault-tolerant, and low-latency storage service optimized for real-time workloads）。

架构

Pulsar采用“存储和服务分离”的两层架构（这是Pulsar区别于其他MQ系统最重要的一点，也是所谓的“下一代消息系统”的核心）：

• Broker：提供发布和订阅的服务（Pulsar的组件）

• Bookie：提供存储能力（BookKeeper的存储组件）

优势是Broker成为了stateless的组件，可以水平扩容（RocketMQ的Broker是包含存储的，是有状态的，Broker的扩容更像是“拆分”）。高可靠，一致性等通过BookKeeper去保证。

上图是Pulsar Cluster的架构：

采用 ZooKeeper 存储元数据，集群配置，作为coordination

• local zk负责Pulsar Cluster内部的配置等

• global zk则用于Pulsar Cluster之间的数据复制等

采用Bookie作为存储设备(大多数MQ系统都采用本地磁盘或者DB作为存储设备)

• Broker负责负载均衡和消息的读取、写入等

• Global replicators负责集群间的数据复制

GEO-REPLICATOIN

多个Broker节点组成一个Pulsar Cluster；多个Pulsar Cluster组成一个Pulsar Instance。

Pulsar通过GEO-REPLICATION支持一个Instance内在不同的地域发送和消费消息。

上图中，Producer P1、P2、P3在不同的Cluster发送给Topic T1的消息，会在Cluster之间进行复制，Consumer C1、C2可以在自己所在的Cluster消费到所有的消息。

当消息被写入Pulsar时，首先消息被持久化在local cluster，之后异步的发送到其他cluster。在没有链接问题的情况下，通常复制的latency相近于网络的RTT。

Pulsar的应用

• 作为普通的Pub-Sub模型的消息队列使用，类似于RocketMQ
• 支持Function（Stream），整合到 Stream 平台（如 Spark）

总结

Apache Pulsar 提供了统一的消费模型，支持 Stream（如 Kafka）和 Queue（如 RabbitMQ）两种消费模型， 支持 exclusive、failover 和 shared 三种消费模式。

同时，Pulsar 提供和 Kafka 兼容的 API，以及 Kafka-On-Pulsar（KoP） 组件来兼容 Kafka 的应用程序，KoP 在 Pulsar Broker 中解析 Kafka 协议，用户不用改动客户端的任何 Kafka 代码就能直接使用 Pulsar。

一句话，Plusar 是对 Kafka 的增强或升级。