下载掌阅APP，畅读海量书库
立即打开
如之前的章节所述，Pulsar 的模块化设计将系统的各项职责分离开，并为每个模块选择最合适的技术。Pulsar的职责之一就是为发布者和订阅者提供连接的接口。
Pulsar Broker除了要承担该职责，还要完成下列任务（如图4-2所示）：
·缓存主题数据
·与Apache BookKeeper、ZooKeeper交互
·Schema校验
·Broker间的通信
·为Pulsar Functions和Pulsar IO提供运行时环境
图4-2 Pulsar节点的底层由Java 基于Java虚拟机实现，Pulsar Functions和Pulsar IO也由Java实现。Pulsar支持几种通过HTTP和TCP在集群内通信的方法
接下来让我们更深入地了解Pulsar Broker。
Pulsar Broker无状态，是因为Pulsar不会在Broker磁盘上存储任何会在消息生命周期中使用到的数据。Pulsar 的这种设计在消息代理中较为独特，因为大多数类似的系统会在某种程度上将消息存储和检索耦合。将Broker作为无状态组件有利有弊。缺点是架构中必须要有其他负责管理状态的系统，并且需要通过某些抽象将 Pulsar 的存储需求转换为存储系统能接受的形式。优点则是计算与存储的需求相互分离，一个容错性更好的存储层得以构建起来。
如果 Pulsar Broker 负责存储主题的状态，那么就需要考虑如何在 Broker 中存储数据，以及如何处理故障等一系列相关的问题。
由于我们刚开始了解Pulsar，我们可以先简单考虑以下三点：
·存储数据
·向集群中增加新节点
·从集群中移除节点
我们已经在第3章中讨论过分布式系统存储数据的方式，特别是在流量较低的系统中存储和读取数据的方式。流量较高的系统需要考虑更多的问题，例如，数据在各个节点上的分布情况和节点故障之类的情况如何影响整个系统。Pulsar 没有选择独自处理复杂的存储问题，而是将Apache BookKeeper作为存储层，并将Broker作为无状态的存储编排组件。
在 BookKeeper 之上，Pulsar使用了一层名为“Managed Ledger”的抽象。Managed Ledger 是 Pulsar Broker 需要存储的消息和在 BookKeeper 中的 Ledger（本章后文会介绍）之间的桥梁。你可以把 Ledger 看作 BookKeeper 中最高级别的存储抽象，Managed Ledger 则是一个API，它会追踪Ledger 的大小、状态，还会把握创建新Ledger的恰当时间。
图 4-3 所示为一个典型的 Pulsar 主题拓扑结构。Broker 1 负责处理主题的读写请求。对于写请求，Broker 会将消息写入属于主题 Ensemble 的所有 BookKeeper 实例（即Bookie 节点）中。对于读请求，Broker 则从存储该 Ledger 数据的 Bookie 中读取消息。Managed Ledger 负责管理该接口。那么，这是否意味着每个读取消息的请求都需要Pulsar Broker从Bookie中获取数据呢？答案是并不一定。Pulsar Broker中有能为消费者缓存部分消息的Managed Ledger缓存。
图4-3 在该Pulsar集群中，Bookie负责存储主题的数据
在流式场景中，每条消息都需要写入 BookKeeper。对于活跃的消费者，Pulsar Broker可以直接从缓存中读取最新消息，然后将其直接投递给消费者，而无须将消息写入BookKeeper后再从中读取。此举减少了对BookKeeper的读写请求（如图4-4所示）。
值得注意的是，虽然 Managed Ledger 可以为订阅主题的消费者缓存消息，但缓存终究只是缓存（如图4-5所示）。缓存的生命周期短暂，创建或销毁缓存十分简单。在缓存中存储数据很方便，但也可能带来一些麻烦，因此，缓存不应该用于永久性的数据储存。所幸，Pulsar Broker 对缓存的使用仅限于缓存数据。我们会在第5章和第6章中更深入地介绍Pulsar消息的生命周期。
图4-4 Pulsar Broker可以直接从缓存中读取消息并将其投递给活跃的消费者
图4-5 Managed Ledger 缓存是Pulsar Broker中一个可配置的缓存，它会缓存近期被写入BookKeeper Ledger中的消息，并提供写入BookKeeper的接口
如本章开头所述，Pulsar 节点与 BookKeeper、ZooKeeper 协同运作是消息平台的基础。毫无疑问，Pulsar Broker 需要与ZooKeeper、BookKeeper 交互，以进行主题管理和一些信息配置。何时以及如何交互完全由 Pulsar Broker 自行决定。为了更好地了解 Broker与BookKeeper、ZooKeeper交互的时机，花一些时间是有意义的。
ZooKeeper 负责存储与 Pulsar 集群有关的所有元数据，包括某主题由哪个 Broker 服务、服务发现的配置，以及其他的一些集群管理信息。存储在 ZooKeeper 中的大部分数据也缓存在Pulsar节点，Broker会根据配置从ZooKeeper中定期拉取新数据。与ZooKeeper交互是Pulsar运行过程中不可缺少的一个环节。
如前文所述，BookKeeper 是 Pulsar 的存储层，所有消息数据都存储在 BookKeeper 中。在存储和读取消息时，Pulsar都需要与 BookKeeper 交互。我们会在第12章中更详细地介绍与BookKeeper交互的接口。
Schema 校验是保证新发布到 Pulsar 主题中的消息都符合特定结构的过程。为了保证消息符合 Schema 定义的结构，Pulsar Broker 利用 Pulsar Schema Registry 进行校验。第6章会介绍Schema 校验的具体过程，但是，由于 Schema 校验意义重大且完全由 Broker负责，我们会先在这里做简要说明。
在 Schema 校验过程中，Broker 有两个主要职责。第一，Broker 负责存储与主题关联的Schema。Broker解答以下问题：
·某主题是否有与之关联的Schema？
·与该主题关联的Schema是什么？
·该主题的Schema是否要求新消息遵循其定义的格式？
此外，Broker还负责校验传输中的消息。Schema校验是端到端消息系统的重要组成部分，在Pulsar中，由Broker承担这个职责。
如前文所述，Broker 负责特定主题消息的写入和读取。当客户端发送主题数据请求时，接收请求的Broker 有可能并不负责该主题的数据。这种情况下会发生什么？如图4-6 所示，每个 Broker 都会根据存储在 ZooKeeper 中的元数据来确定自己是不是主题的所有者（负责处理主题相关的请求）。如果它不是主题的所有者，它会确定哪个 Broker是所有者。为了发送或接收消息，Broker可能会将客户端请求路由至正确的Broker。
图4-6 Broker 1不是主题A的所有者，因此，它会将生产者重新定向到正确的Broker
我在前文强调过 Pulsar 模块化设计的重要性。通过上文的内容，你已经了解了 Broker的诸多职责。或许，你会认为 Pulsar 的设计还可以更模块化，但在考虑模块化时，需要关注两个很关键的要素。第一，将某些职责从Broker中移除后交由其他组件负责是否合理？第二，将这些职责交给别的组件是否一定能提高 Pulsar 的可靠性和可扩展性？通常来说，这两个问题的答案是否定的，但Pulsar IO和Pulsar Functions是例外。
Pulsar 项目提供了使用 Pulsar Broker和诸如 Pulsar Functions、Pulsar IO等扩展功能的简单入门方法。无须额外投入，Pulsar 新用户即可轻松使用 Pulsar Functions 或者 Pulsar IO。这种便捷配置的限制因素是Broker，因为Broker是Pulsar中承担吞吐量的主要组件。一个集群每秒可以接收的消息数量在很大程度上由 Broker 的可用性决定，如果 Broker忙于处理Pulsar Functions或者Pulsar IO任务，那么整个系统的性能都会受到影响。
在很多情况下，性能下降并不是问题，但是，对于一定规模的集群来说，将Pulsar IO或者Pulsar Functions 迁移到其他集群是一种性能提升手段。所幸，Pulsar 正好提供了相关机制。