Pulsar Architecture Overview（架构概述）
目录
1、Brokers 代理服务器
2、Clusters 集群
3、Metadata store 元数据存储
4、Configuration store 配置存储
5、Persistent storage 持久化存储
（1）Apache BookKeeper 存储实体
（2）Ledgers 分类账
（3）Journal storage 日志存储
6、Pulsar proxy（代理）
7、Service discovery 服务发现
从一个最高层级来看，Pulsar 实例可以由一个或多个 Pulsar 集群组成。在该 Pulsar 实例中的子集群可以从其他子集群中复制数据。
Pulsar 集群：
- 在 Pulsar 集群中，有一个或多个 Brokers，Broker 可以处理从生产者传入的消息（多个进行负载均衡）、并向消费者分发这些消息，同时可以与 Pulsar 配置的存储通信来处理各种协调任务、也可向 BookKeeper 实例存储消息、依靠特定的 ZooKeeper 集群来完成某些任务等等。// broker 能做什么？处理消息、分发消息、存储消息、协调任务
- BookKeeper 集群由一个和多个处理消息持久存储的 bookies 组成。// 存储集群
- ZooKeeper 是 Pulsar 集群中负责协调各个 cluster 之间协作任务的组件（也可以是集群）。// ZooKeeper 集群
下图为一个 Pulsar 集群提供了说明：// 三个组件：Broke（理解为处理器）、BookKeeper（理解为存储器）、ZooKeeper（理解为协调器）
从更广泛的实例级别来看，一个实例级别的 ZooKeeper 集群可以调用配置存储，来处理涉及多个集群的协调任务，比如，异地备份。// 实例级别，可以理解为应用级别或应用层次
1、Brokers 代理服务器
Brokers 是一个无状态组件，主要负责运行以下两个组件：
- HTTP 代理服务器：该服务器对外为管理任务提供 rest 风格的 API，并且为生产者和消费者提供主题查找服务。生产者通过该服务器发布消息，消费者通过该服务器消费消息。// 管理任务可使用管理工具包进行操作
- 消息分发器（传输数据）：它是一个基于自定义二进制协议的异步 TCP 服务器，用于所有数据传输。// 也是一个服务器，用来传输数据
为了提高性能，broker 通常从被管理的 Ledger 缓存中进行消息分派，除非 backlog 日志（积压消息）超过了缓存的容量。如果因为 backlog 日志太大而导致缓存不可用，broker 将会开始从 BookKeeper 中读取消息，然后再进行分发。// BookKeeper 是 pulsar 的持久化存储， backlog 日志用来存储没有被消费的消息，Ledger 是比 BookKeeper 更小的存储分片
最后，为了支持全局主题的异地备份，broker 可以操作本地的复制器，该复制器会跟踪本地已经发布的数据，并使用 Pulsar Java 客户端库将这些数据推送到远程的区域。
对于怎样管理 Pulsar brokers，请参阅更详细的指南。
2、Clusters 集群
一个 Pulsar 实例由一个或多个 Pulsar Clusters 组成，集群依次包括下边几个部分：
- 一个或多个 Pulsar Brokers // 代理服务器组件
- 一个 ZooKeeper 投票机制，用来支持集群级别的配置和协作 // 协调组件
- 一组 Bookies，用来对消息进行持久化存储 // 存储组件
通过异地备份，集群节点之间可以进行数据复制。
对于怎样管理 Pulsar clusters，请参阅更详细的指南。
3、Metadata store 元数据存储
Pulsar 元数据存储会保存 Pulsar 集群中的所有元数据，比如，主题元数据、schema、broker 加载的数据等。Pulsar 使用 Apache ZooKeeper 来进行元数据存储、集群配置和集群协调信息。Pulsar 元数据存储可以部署在单独的 ZooKeeper 集群上，也可以部署在已有的 ZooKeeper 集群上。一般情况下，你可以使用同一个 ZooKeeper 集群来进行 Pulsar 元数据存储和 BookKeeper 元数据存储。但是，当你把 Pulsar Brokers 连接到已有的 ZooKeeper 集群上时，你需要分别为 Pulsar 元数据存储和 BookKeeper 元数据存储单独部署一个 ZooKeeper 集群。// 为什么呢？会跟已有的 Zookeeper 的某些数据冲突吗？
Pulsar 还支持更多元数据后端服务，包括etcd 和 RocksDB （仅适用于单独部署的 Pulsar）。
在 Pulsar 实例中：// 集群配置和集群协调信息有哪些？
- 仲裁配置存储（A configuration store quorum），存储租户、命名空间以及其他需要全局一致的数据的配置。
- 每个 Pulsar 集群都拥有自己本地的 ZooKeeper 集群，用于存储特定的集群配置和集群协作信息。所谓的集群协作信息，指的是，哪些 brokers 负责哪些主题以及这些 brokers 拥有哪些元数据，这些 brokers 的负载报告、还有 BookKeeper Ledger 的元数据等信息。
4、Configuration store 配置存储
配置存储，存储 Pulsar 实例的所有配置信息，比如，集群配置、租户配置、命名空间配置、分区主题的相关配置等等。一个 Pulsar 实例（instance）可以由一个本地实例（cluster） 、或者多个本地实例，甚至多个跨区域的实例组成。所以，在一个 Pulsar 实例（instance）中，配置存储中的数据是可以跨多个集群进行共享的。 配置存储可以部署在单独的 ZooKeeper 集群上，也可以部署在已有的 ZooKeeper 集群上。// 这里单独的和已有的是相互对立的，单独的 ZooKeeper 实例可以理解为新的 ZooKeeper 实例
5、Persistent storage 持久化存储
Pulsar 为应用程序提供可靠的消息传递服务。如果消息成功到达了 Pulsar Broker，它将被传递到其预定的目标。
这种可靠的消息传递要求没有被消费者确认消费的消息都能够被持久化的存储，直到它们被消费者消费，这种消息传递模式通常称为持久化消息传递。在 Pulsar 中，所有的消息都拥有 N 个备份被存储和同步在磁盘上，比如，跨两台服务器的 4 个备份，在每台服务器上都拥有多个 RAID 镜像卷。// 一条消息，多个备份
（1）Apache BookKeeper 存储实体
Pulsar 使用 Apache BookKeeper 对消息进行持久化存储。Apache BookKeeper 是一个分布式的预写日志（WAL）系统，为 Pulsar 提供了许多关键优势：// 预写日志，就是操作前先在日志中记录该操作，方便后续数据恢复或排错。BookKeeper 由多个 Bookies 组成。
- 它使 Pulsar 能够使用很多独立的日志，这些日志称为 ledgers 。随着时间的推移，Pulsar 可以为主题创建多个 Ledgers 。
- 它为参与复制的有序数据提供了非常高效的存储。
- 它保证了在各种系统故障场景中，Ledgers 上的读取一致性。
- 它提供了在 Bookies 之间均匀的 I/O 分布。// 负载均衡，读写平衡
- 它在容量和吞吐量上都是可以水平可扩展的。你可以通过向集群中添加更多的 bookies，快速的提高 BookKeeper 的容量。
- Bookies 被设计用来管理数千个同时读写的 ledgers。通过使用多个磁盘设备（一个用于日志存储，另一个用于常规数据存储），Bookies 能够将读操作和写入操作的延迟隔离开来。// 支持同时读写，写的时候不影响读的效率，因为写的是新数据，所以不存在脏读的问题。
除了消息数据以外，游标也持久化存储在 BookKeeper 中。游标是消费者的订阅位置。BookKeeper 使 Pulsar 能够以可扩展的方式存储消费者的消费位置。
目前，Pulsar 支持消息的持久化存储。这就解释了所有主题名称中的持久性。下面是一个示例：
persistent://my-tenant/my-namespace/my-topic
Pulsar 同时也支持非持久化（non-persistent）的消息主题。
你可以在下图中看到 Brokers 和 Bookies 是如何互动的：// Broker 把数据存储在多个 Bookie 上
（2）Ledgers 分类账
Ledger 是一种通过单独的写，仅可以做追加的数据结构，它被分配到多个 BookKeeper 存储节点上，或者 Bookies 上。Ledger 上的数据（entries）可以被复制到多个 Bookies 上，它本身具有非常简单的语义：
- Pulsar Broker 可以创建 Ledger，并往 Ledger 中添加数据，或者关闭 Ledger
- 当 Ledger 被关闭后，不再支持写入操作，所以 Ledger 只能以只读模式打开
- 当 Ledger 中的数据不再需要时，整个 Ledger 就可以从系统中删除
// Ledger 由 Broker 进行操作，只能添加，不能修改，数据以 Ledger 为单位进行删除
Ledger 读取一致性
Bookkeeper 的主要优势在于，它可以在出现故障时保证 Ledgers 的读取一致性。由于 Ledger 只能通过单个线程进行写入，因此该线程可以非常有效地向 Ledger 中随意的添加数据，而无需和其他线程进行竞争。当程序奔溃后，Ledger 会执行一个恢复机制，该机制会确定 Ledger 的最终状态，并且确定最后提交到 Ledger 中的数据。所以，经过 Ledger 恢复机制，所有的 Readers 都能看到完全相同的内容。// Ledger 本身就是一个日志格式的文件，在介绍 Bookkeeper 也提到了
各个名词之间的关系：Bookkeeper -> Bookies -> Ledgers -> entries(具体数据)
Managed ledgers（单个主题的存储层）
考虑到 Bookkeeper Ledgers 提供了一个单独的日志抽象接口，因此，在 Ledgers 之上开发了一个库，称为 Managed ledgers，它表示单个主题的存储层。一个 Managed ledger 表示了该主题一连串消息的抽象，这些消息都是通过一个写入程序不断向后追加而保存的，同时还保存了多个游标的信息，每个游标都记录了与它们关联的消费者的消费位置。// 表示单个主题的消息和游标的抽象
在 Pulsar 内部，单个 Managed Ledger 使用多个 BookKeeper Ledgers 来存储数据。使用多个 Ledgers 进行数据存储，主要有两个原因：
-
当写入失败后，Ledger 不可以再进行写操作，需要重新创建新的 Ledger 。// 数据结构本身的限制
-
当 Ledger 中的所有游标都消费完了 Ledger 中的消息时，Ledger 可以被删除。这样做，可以允许 Ledgers 定期的回滚。// 空间重复利用
（3）Journal storage 日志存储
在 BookKeeper 中，日志文件用来存储 BookKeeper 的事务日志。在对 Ledger 进行更改之前，Bookie 需要确保将该事务写入持久（非易失性）存储。一但 Bookie（注意，不是 Broker）启动，就会创建一个新的日志文件，或者当达到日志文件大小的阈值时，也会创建一个新的日志文件。（使用 journalMaxSizeMB 配置日志文件的大小）
6、Pulsar proxy（代理）
Pulsar 客户端与 Pulsar 交互的一种方法是直接连接到 Pulsar 的 Broker。但是，在某些情况下，因为客户端无法直接访问到 Broker 的地址，这种直接连接的方法，就变得不可行或者不可取。比如，如果你在云端环境或这 Kubernetes 等类似的平台上运行 Pulsar，客户端就无法直接连接到 Pulsar 的 Broker。
Pulsar proxy 为上述问题提供了解决方案，那就是使用 Pulsar proxy 作为集群中所有 Brokers 的唯一网关。运行 Pulsar proxy 后，所有客户端与 Pulsar 实例（cluster）的连接都会通过 Pulsar proxy 进行，而无需与 Brokers 直接通信。// 跟 Spring Cloud 很像，使用统一网关，屏蔽后台服务
为了提高性能和容错性，你可以运行任意多个的 Pulsar proxy 实例。
从架构上讲，Pulsar proxy 可以从 ZooKeeper 获取它需要的所有信息。当在一台机器上启动 proxy 时，你只需要为特定的集群（cluster-specific）提供元数据存储的连接（字符串形式），以及所有实例的配置存储集群的连接。下面是一个示例：// 需要配置两个属性
$ cd /path/to/pulsar/directory
$ 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 proxy docs（文献）
一些使用 Pulsar proxy 的文档，请点击这里。
关于 Pulsar proxy，有一些重要的点需要了解：
- 当使用 Pulsar proxy 时，客户端（clients）无需提供任何特殊的配置。除了更新 IP 之外（使用 Pulsar proxy 的 IP），无需更改现有应用程序的其他配置。
- Pulsar proxy 支持TLS 加密和身份验证。
7、Service discovery 服务发现
客户端使用一个单独的 URL 连接到 Pulsar Brokers 后，需要能够与整个 Pulsar 实例进行通讯。// 注意，Pulsar 实例中包含了一个或多个 Pulsar Cluster 集群。
你可以使用自己的服务发现系统。但是，当你使用自己的服务发现系统，需要满足一个要求，那就是当客户端向端点（endpoint）发出一个 HTTP 请求时，比如：http://pulsar.us-west.example.com:8080，客户端需要能够被重定向到期望集群的一个活跃的 Broker 上，无论该要求是通过 DNS、HTTP 或 IP 重定向，或是其他方式实现的。// 服务发现需要支持正确的重定向
下图描述了 Pulsar 的服务发现：
在上图中，Pulsar cluster 可通过单个的 DNS 名称：pulsar-cluster.acme.com 进行寻址。例如，Python 客户端可以像这样访问该 Pulsar cluster：
from pulsar import Client
client = Client('pulsar://pulsar-cluster.acme.com:6650')注意事项
在 Pulsar 中，每一个主题仅由一个 Broker 处理。客户端发出的读取、更新或删除主题的初始请求可能会发送给一个与此主题不相关的 Broker（非正确的主题的代理）。如果该 Broker 无法处理此主题的请求，它会将请求重定向到合适的 Broker 进行处理。// 服务发现的核心就是支持正确的重定向。
点击回到首页