Pulsar 入门实战(2)--特性及架构

Pulsar 入门实战(2)--特性及架构

Apache Pulsar是一种分布式消息传递平台，以其独特的架构和丰富的特性在大数据和流处理领域广受欢迎。本文将深入探讨Pulsar的各个组件和工作机制，帮助读者全面理解这一强大的消息队列系统。

1、Pulsar 特性

• 多集群支持：Pulsar实例原生支持多个集群，并且在集群之间实现了无缝的地理复制消息。
• 低延迟：提供极低的发布和端到端延迟。
• 高扩展性：支持无缝扩展至超过一百万个主题。
• 简单易用：提供简单的客户端API，支持Java、Go、Python和C++等多种语言。
• 灵活的订阅模式：支持多种订阅类型，包括独占、共享和故障转移。
• 持久化存储：通过Apache BookKeeper提供持久化消息存储，保证消息传递的可靠性。
• 流处理能力：无服务器轻量计算框架Pulsar Functions提供流原生数据处理能力。
• 数据移动框架：无服务器连接器框架Pulsar IO基于Pulsar Functions构建，使得数据在Apache Pulsar内外的移动更加容易。
• 分层存储：支持分层存储，在数据老化时将其从热/温存储卸载到冷/长期存储（例如S3和GCS）。

2、架构

2.1、架构概述

在最高级别上，Pulsar实例由一个或多个Pulsar集群组成。实例内的集群间会同步数据。一个Pulsar包含以下组件：

• Broker：负责处理和负载均衡来自生产者的消息，并将消息分派给消费者，与Pulsar配置存储通信以处理各种协调任务，将消息存储在BookKeeper实例（又称bookies）中，依赖于ZooKeeper集群执行某些任务等。
• BookKeeper集群：一个或多个bookie组成的集群，负责处理消息的持久存储。
• ZooKeeper集群：负责处理Pulsar集群之间的协调任务。

下图表示了一个Pulsar集群：

在更广泛的实例级别，一个称为配置存储的实例级ZooKeeper集群处理涉及多个集群的协调任务，例如地理复制。

2.2、Brokers

Broker是一个无状态组件，主要负责运行另外两个组件：

• HTTP服务器：暴露REST API，用于管理任务和生产者与消费者的主题查找。生产者连接到Broker以发布消息，消费者连接到Broker以消费消息。
• 调度程序：是一个基于自定义二进制协议的异步TCP服务器，用于所有数据传输。

为了提高性能，消息通常会从受控分布式日志缓存中分派，除非积压超过了缓存大小。如果积压量过大，超出了缓存的处理能力，Broker将从BookKeeper中读取条目。

最后，为了支持全局主题的地理复制，Broker管理复制器，这些复制器追踪本地区发布的条目，并使用Pulsar Java客户端将它们重新发布到远程区域。

2.3、集群

一个Pulsar实例包括一个或多个Pulsar集群。集群本身由以下组成：

• 一个或多个Broker
• 用于集群级配置和协调的ZooKeeper集群
• 用于消息持久存储的bookie集合

可以通过地理复制在集群间进行数据复制。

2.4、元数据存储

Pulsar的元数据存储维护着整个Pulsar集群的所有元数据，例如主题元数据、模式、Broker负载数据等。Pulsar使用ZooKeeper来存储元数据、进行集群配置和协调。Pulsar的元数据存储可以单独部署在一个ZooKeeper集群上，也可以部署在已有的ZooKeeper集群上。可以使用同一个ZooKeeper集群来存储Pulsar的元数据和BookKeeper的元数据。如果想要部署Broker以连到现有的BookKeeper集群，那么需要分别为Pulsar元数据存储和BookKeeper元数据存储部署独立的ZooKeeper集群。

Pulsar还支持更多的元数据后端服务，包括etcd和RocksDB（仅适用于单机的Pulsar）。

在Pulsar实例中：

• 配置存储中存储了租户、命名空间及其他需要全局一致性的实体配置。
• 每个集群都有自己的本地ZooKeeper集群，用于存储集群特定的配置和协调信息，例如哪些Broker负责哪些主题、所有权元数据、Broker负载报告、BookKeeper ledger元数据等。

2.5、配置存储

配置存储是一个ZooKeeper集群，用于处理与配置相关的任务，并维护Pulsar实例的所有配置，例如集群、租户、命名空间、分区主题相关的配置等。一个Pulsar实例可以有一个本地集群、多个本地集群或多个跨区域集群。因此，配置存储可以在Pulsar实例中的多个集群之间共享。配置存储可以使用单独的ZooKeeper集群，也可以使用现有的ZooKeeper集群。

2.6、持久存储

Pulsar为应用程序提供了可靠的消息传递保证。如果消息成功到达Pulsar Broker，它将被传递给其预期的目标。

这种保证要求非确认的消息在持久化存储中保留，直到传递给消费者并收到确认。这种消息传递模式通常称为持久化消息传递。在Pulsar中，所有消息的N个副本都被存储并同步到磁盘上，例如，在两台服务器上通过镜像RAID卷存储4个副本。

2.6.1、Apache BookKeeper

Pulsar使用Apache BookKeeper进行持久化消息存储。BookKeeper是一个分布式的预写式日志（WAL）系统，为Pulsar提供了几个关键优势：

• 它使Pulsar能够利用许多独立的日志(ledger)。随着时间的推移，可以为主题创建多个ledger。
• 它为处理条目复制的顺序数据提供非常高效的存储。
• 它在各种系统故障情况下保证ledger的读一致性。
• 它能够在bookies之间均匀分配I/O。
• 它在容量和吞吐量上具有水平可扩展性。通过向集群添加更多的bookie，可以立即增加容量。
• Bookies被设计为处理数千个ledger的并发读写。通过使用多个磁盘设备--一个用于日志，另一个用于一般存储--bookies可以将读操作与有延迟的写操作隔离开来

除了消息数据外，BookKeeper还持久存储游标。游标是消费者的订阅位置。BookKeeper使得Pulsar能够以可扩展的方式存储消费者的位置。

目前，Pulsar支持持久化消息存储。这体现在所有主题名称中的"persistent"一词。以下是一个示例：

persistent://my-tenant/my-namespace/my-topic

Pulsar还支持临时的非持久化消息存储。

下图为Brokers和bookies之间的交互示意图：

2.6.2、Ledgers

ledger是一种仅追加的数据结构，只有一个写入者，它被分配给多个BookKeeper存储节点--bookie。ledger条目会被复制到多个bookie。ledger本身具有非常简单的语义：

• Pulsar Broker节点可以创建ledger，向ledger追加条目，并关闭ledger。
• 一旦ledger被关闭--无论是显式关闭还是因为写入进程崩溃--它只能以只读模式重新打开。
• 最后，当不再需要ledger中的条目时，可以从系统中（所有bookies中）删除整个ledger。

Ledger读一致性

Bookkeeper的主要优势在于，在发生故障时，它保证ledger的读一致性。由于ledger只能由单个进程写入，该进程可以非常高效地追加条目，无需获得共享锁。在发生故障后，ledger将经历恢复过程，该过程将最终确定ledger的状态，并确定最后提交的条目。在那之后，所有读取ledger的操作都保证能看到完全相同的内容。

托管ledgers

鉴于Bookkeeper ledger提供了单一的日志抽象，因此在ledger之上开发了一个名为"managed ledger"的库，它代表了单个主题的存储层。托管ledger表示消息流的抽象，单一的写入者在流的末尾不断追加消息；并且有多个消费者游标在消费这个流，每个游标都有其关联的位置。

在内部，单个托管ledger使用多个BookKeeper ledger来存储数据。有两个理由使用多个ledger：

• 在发生故障后，ledger不再可写，需要创建一个新的ledger。
• 当所有游标消费完ledger中的消息后，可以删除该ledger。这允许定期滚动ledger。

2.6.3、Journal存储

在BookKeeper中，Journal文件包含BookKeeper事务日志。在对ledger进行更新之前，Bookie需要确保将描述更新的事务写入持久（非易失性）存储。一旦Bookie启动或者旧的journal文件大小达到了阈值（通过参数journalMaxSizeMB配置），就会创建一个新的journal文件。

2.7、Pulsar代理

Pulsar客户端与Pulsar集群进行交互的一种方式是直接连接到Pulsar Broker。然而，在某些情况下，这种直接连接不可行或不可取，因为客户端无法直接访问Broker地址。例如，如果在云环境、Kubernetes或类似的平台上运行Pulsar，那么直接连接客户端到Broker的方式可能是不可行的。

Pulsar代理通过充当集群中所有Broker的单一网关，提供了解决这个问题的方案。如果运行Pulsar代理（再次强调，这是可选的），客户端将通过代理与Pulsar集群连接，而不是直接与Broker通信。

为了性能和容错性，请根据需要运行多个Pulsar代理实例。

在架构上，Pulsar代理从ZooKeeper获取其所需的所有信息。在启动代理时，只需提供元数据存储和配置存储的地址。以下是一个示例：

bin/pulsar proxy \
 --metadata-store zk:my-zk-1:2181,my-zk-2:2181,my-zk-3:2181 \
 --configuration-metadata-store zk:my-zk-1:2181,my-zk-2:2181,my-zk-3:2181

Pulsar代理的详细说明，可参阅Pulsar代理管理文档。

关于Pulsar代理的一些重要事项：

• 客户端使用Pulsar代理时无需提供任何特定的配置。不需要更新现有应用程序的客户端配置，除服务URL的IP改变了（例如，在Pulsar代理上运行负载均衡器）。
• Pulsar代理支持TLS加密和mTLS身份验证。

2.8、服务发现

服务发现是一种机制，它使客户端能够使用单个URL与整个Pulsar实例进行交互。

如果愿意，可以使用自己的服务发现系统。如果使用自己的系统，只有一个要求：当客户端对一个地址发起HTTP请求，比如http://pulsar.us-west.example.com:8080时，需要将客户端重定向到集群中的某个活跃Broker，可以通过DNS、HTTP或IP重定向，或者其他方式实现。

下图说明了Pulsar的服务发现：

在这个图示中，Pulsar集群通过一个单一的DNS名称进行寻址：pulsar-cluster.acme.com。Python客户端可以这样访问这个Pulsar集群：

from pulsar import Client
client = Client('pulsar://pulsar-cluster.acme.com:6650')

注意：在Pulsar中，每个主题仅由一个Broker处理。客户端对主题的初始读取、更新或删除请求可能会发送到不是该主题所有者的Broker。如果Broker无法处理此主题的请求，它会将请求重定向到适当的Broker。

参考：https://pulsar.apache.org/docs/3.3.x/concepts-architecture-overview/。