一文读懂 Apache Pulsar详细解析和实战运用_pulsar使用

Pulsar 介绍

Apache Pulsar 作为 Apache 软件基金会顶级项目，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、跨区域复制、具有强一致性、高吞吐、低延迟及高可扩展性等流数据存储特性。

Pulsar 诞生于 2012 年，最初的目的是为在 Yahoo 内部，整合其他消息系统，构建统一逻辑、支撑大集群和跨区域的消息平台。当时的其他消息系统（包括 Kafka），都不能满足 Yahoo 的需求，比如大集群多租户、稳定可靠的 IO 服务质量、百万级 Topic、跨地域复制等，因此 Pulsar 应运而生。

Pulsar 的关键特性如下：

• Pulsar 的单个实例原生支持多个集群，可跨机房在集群间无缝地完成消息复制。
• 极低的发布延迟和端到端的延迟。
• 可无缝扩展到超过一百万个 Topic。
• 简单的客户端 API，支持 Java、Go、Python 和 C++.
• 支持多种 Topic 订阅模式 （独占订阅、共享订阅、故障转移订阅）。
• 通过 Apache BookKeeper 提供的持久化消息存储机制保证消息传递。
• 由轻量级的 Serverless 计算框架 Pulsar Functions 实现流原生的数据处理。
• 基于 Pulsar Functions 的 serverless connector 框架 Pulsar IO 使得数据更容易移入、移出 Apache Pulsar。
• 分层存储可在数据陈旧时，将数据从热存储卸载到冷/长期存储（如S3、GCS）中。

社区：

目前 Apache Pulsar 在 Github 的 star 数量是10K+，共有470+个 contributor。并且正在持续更新，社区的活跃度比较好。

概念

Producer

消息的源头，也是消息的发布者，负责将消息发送到 topic。

Consumer

消息的消费者，负责从 topic 订阅并消费消息。

Topic

消息数据的载体，在 Pulsar 中 Topic 可以指定分为多个 partition，如果不设置默认只有一个 partition。

Broker

Broker 是一个无状态组件，主要负责接收 Producer 发送过来的消息，并交付给 Consumer。

BookKeeper

分布式的预写日志系统，为消息系统比 Pulsar 提供存储服务，为多个数据中心提供跨机器复制。

Bookie

Bookie 是为消息提供持久化的 Apache BookKeeper 的服务端。

Cluster

Apache Pulsar 实例集群，由一个或多个实例组成。

云原生架构

Apache Pulsar 采用计算存储分离的一个架构，不与计算逻辑耦合在一起，可以做到数据独立扩展和快速恢复。计算存储分离式的架构随着云原生的发展，在各个系统中出现的频次也是越来越多。Pulsar 的 Broker 层就是一层无状态的计算逻辑层，主要负责接收和分发消息，而存储层由 Bookie 节点组成，负责消息的存储和读取。

Pulsar 的这种计算存储分离式的架构，可以做到水平扩容不受限制，如果系统的 Producer、Consumer 比较多，那么就可以直接扩容计算逻辑层 Broker，不受数据一致性的影响。如果不是这种架构，我们在扩容的时候，计算逻辑和存储都是实时变化的，就很容易受到数据一致性的限制。同时计算层的逻辑本身就很复杂容易出错，而存储层的逻辑相对简单，出错的概率也比较小，在这种架构下，如果计算层出现错误，可以进行单方面恢复而不影响存储层。

Pulsar 还支持数据分层存储，可以将旧消息移到便宜的存储方案中，而最新的消息可以存到 SSD 中。这样可以节约成本、最大化利用资源。

集群架构

Pulsar的集群由多个 Pulsar 实例组成的，其中包括

• 多个 Broker 实例，负责接收和分发消息
• 一个 ZooKeeper 服务，用来协调集群配置
• BookKeeper 服务端集群 Bookie，用来做消息的持久化
• 集群之间通过跨地域复制进行消息同步

设计原理

pulsar 采用发布-订阅的设计模式（pub-sub）,在该设计模式中 producer 发布消息到 topic ，consumer 订阅 topic 中的消息并在处理完成之后发送 ack 确认。