原创：Sijie Guo

翻译：翟佳

在上一篇文章中，咱们深入探讨了 Apache Pulsar 的音讯模型，该零碎对立了高性能的流 和 灵便的队列。比照展现了 Apache Pulsar 和 Apache Kafka 实现消息传递模型中音讯生产，确认和保留的工作形式。在这篇文章中，咱们将介绍 Apache Pulsar 背地的一些零碎架构和设计理念，并最初与 Apache Kafka 的架构进行一些比拟。

Pulsar 的分层架构

Apache Pulsar 和其余音讯零碎最基本的不同是采纳分层架构。Apache Pulsar 集群由两层组成：无状态服务层，由一组接管和传递音讯的 Broker 组成；以及一个有状态长久层，由一组名为 bookies 的 Apache BookKeeper 存储节点组成，可长久化地存储音讯。下图显示了 Apache Pulsar 的典型部署。

在 Pulsar 客户端中提供生产者和消费者（Producer & Consumer）接口，应用程序应用 Pulsar 客户端连贯到 Broker 来公布和生产音讯。

Pulsar 客户端不间接与存储层 Apache BookKeeper 交互。客户端也没有间接的 Zookeeper 拜访权限。这种隔离，为 Pulsar 实现平安的多租户对立身份验证模型提供了根底。

Apache Pulsar 为客户端提供多种语言的反对，包含 Java，C ++，Python，Go 和 Websockets。

Apache Pulsar 还提供了一组兼容 Kafka 的 API，用户能够通过简略地更新依赖关系并将客户端指向 Pulsar 集群来迁徙现有的 Kafka 应用程序，这样现有的 Kafka 应用程序能够立刻与 Apache Pulsar 一起应用，无需更改任何代码。

Broker 层 – 无状态服务层

Broker 集群在 Apache Pulsar 中造成无状态服务层。服务层是“无状态的”，因为 Broker 实际上并不在本地存储任何音讯数据。无关 Pulsar 主题的音讯，都被存储在分布式日志存储系统（Apache BookKeeper）中。咱们将在下一节中更多地探讨 BookKeeper。

每个主题分区（Topic Partition）由 Pulsar 调配给某个 Broker，该 Broker 称为该主题分区的所有者。Pulsar 生产者和消费者连贯到主题分区的所有者 Broker，以向所有者代理发送音讯并生产音讯。

如果一个 Broker 失败，Pulsar 会主动将其领有的主题分区挪动到群集中残余的某一个可用 Broker 中。这里要说的一件事是：因为 Broker 是无状态的，当产生 Topic 的迁徙时，Pulsar 只是将所有权从一个 Broker 转移到另一个 Broker，在这个过程中，不会有任何数据复制产生。

下图显示了一个领有 4 个 Broker 的 Pulsar 集群，其中 4 个主题分区散布在 4 个 Broker 中。每个 Broker 领有并为一个主题分区提供音讯服务。

BookKeeper 层 – 长久化存储层

Apache BookKeeper 是 Apache Pulsar 的长久化存储层。Apache Pulsar 中的每个主题分区实质上都是存储在 Apache BookKeeper 中的分布式日志。

每个分布式日志又被分为 Segment 分段。每个 Segment 分段作为 Apache BookKeeper 中的一个 Ledger，均匀分布并存储在 BookKeeper 群集中的多个 Bookie（Apache BookKeeper 的存储节点）中。Segment 的创立机会包含以下几种：基于配置的 Segment 大小；基于配置的滚动工夫；或者当 Segment 的所有者被切换。

通过 Segment 分段的形式，主题分区中的音讯能够平均和均衡地散布在群集中的所有 Bookie 中。这意味着主题分区的大小不仅受一个节点容量的限度；相同，它能够扩大到整个 BookKeeper 集群的总容量。

上面的图阐明了一个分为 x 个 Segment 段的主题分区。每个 Segment 段存储 3 个正本。所有 Segment 都散布并存储在 4 个 Bookie 中。

Segment 为核心的存储

存储服务的分层的架构 和 以 Segment 为核心的存储 是 Apache Pulsar（应用 Apache BookKeeper）的两个要害设计理念。这两个根底为 Pulsar 提供了许多重要的益处：

• 无限度的主题分区存储
• 即时扩大，无需数据迁徙
• 无缝 Broker 故障复原
• 无缝集群扩大
• 无缝的存储（Bookie）故障复原
• 独立的可扩展性

上面咱们别离开展来看着几个益处。

无限度的主题分区存储

因为主题分区被宰割成 Segment 并在 Apache BookKeeper 中以分布式形式存储，因而主题分区的容量不受任何繁多节点容量的限度。相同，主题分区能够扩大到整个 BookKeeper 集群的总容量，只需增加 Bookie 节点即可扩大集群容量。这是 Apache Pulsar 反对存储有限大小的流数据，并可能以高效，分布式形式解决数据的要害。应用 Apache BookKeeper 的分布式日志存储，对于对立音讯服务和存储至关重要。

即时扩大，无需数据迁徙

因为音讯服务和音讯存储分为两层，因而将主题分区从一个 Broker 挪动到另一个 Broker 简直能够刹时内实现，而无需任何数据从新均衡（将数据从一个节点从新复制到另一个节点）。这一个性对于高可用的许多方面至关重要，例如集群扩大；对 Broker 和 Bookie 失败的疾速应答。我将应用例子在下文更具体地进行解释。

• 无缝 Broker 故障复原

下图阐明了 Pulsar 如何解决 Broker 失败的示例。在例子中 Broker 2 因某种原因（例如停电）而断开。Pulsar 检测到 Broker 2 已敞开，并立刻将 Topic1-Part2 的所有权从 Broker 2 转移到 Broker 3。在 Pulsar 中数据存储和数据服务拆散，所以当代理 3 接管 Topic1-Part2 的所有权时，它不须要复制 Partiton 的数据。如果有新数据到来，它立刻附加并存储为 Topic1-Part2 中的 Segment x + 1。Segment x + 1 被散发并存储在 Bookie1, 2 和 4 上。因为它不须要从新复制数据，所以所有权转移立刻产生而不会就义主题分区的可用性。

• 无缝集群容量扩大

下图阐明了 Pulsar 如何解决集群的容量扩大。当 Broker 2 将音讯写入 Topic1-Part2 的 Segment X 时，将 Bookie X 和 Bookie Y 增加到集群中。Broker 2 立刻发现新退出的 Bookies X 和 Y。而后 Broker 将尝试将 Segment X + 1 和 X + 2 的音讯存储到新增加的 Bookie 中。新减少的 Bookie 立即被应用起来，流量立刻减少，而不会从新复制任何数据。除了机架感知和区域感知策略之外，Apache BookKeeper 还提供资源感知的搁置策略，以确保流量在群集中的所有存储节点之间保持平衡。

• 无缝的存储（Bookie）故障复原

下图阐明了 Pulsar（通过 Apache BookKeeper）如何解决 bookie 的磁盘故障。这里有一个磁盘故障导致存储在 bookie 2 上的 Segment 4 被毁坏。Apache BookKeeper 后盾会检测到这个谬误并进行复制修复。

Apache BookKeeper 中的正本修复是 Segment（甚至是 Entry）级别的多对多疾速修复，这比从新复制整个主题分区要精密，只会复制必须的数据。这意味着 Apache BookKeeper 能够从 bookie 3 和 bookie 4 读取 Segment 4 中的音讯，并在 bookie 1 处修复 Segment 4。所有的正本修复都在后盾进行，对 Broker 和利用通明。即便有 Bookie 节点出错的状况产生时，通过增加新的可用的 Bookie 来替换失败的 Bookie，所有 Broker 都能够持续承受写入，而不会就义主题分区的可用性。

独立的可扩展性

因为音讯服务层和长久存储层是离开的，因而 Apache Pulsar 能够独立地扩大存储层和服务层。这种独立的扩大，更具老本效益：

当您须要反对更多的消费者或生产者时，您能够简略地增加更多的 Broker。主题分区将立刻在 Brokers 中做均衡迁徙，一些主题分区的所有权立刻转移到新的 Broker。

当您须要更多存储空间来将音讯保留更长时间时，您只需增加更多 Bookie。通过智能资源感知和数据搁置，流量将主动切换到新的 Bookie 中。Apache Pulsar 中不会波及到不必要的数据搬迁，不会将旧数据从现有存储节点从新复制到新存储节点。

和 Kafka 的比照

Apache Kafka 和 Apache Pulsar 都有相似的音讯概念。客户端通过主题与音讯零碎进行交互。每个主题都能够分为多个分区。然而，Apache Pulsar 和 Apache Kafka 之间的基本区别在于 Apache Kafka 是以分区为存储核心，而 Apache Pulsar 是以 Segment 为存储核心。

上图显示了以分区为核心和以 Segment 为核心的零碎之间的差别。

在 Apache Kafka 中，分区只能存储在单个节点上并复制到其余节点，其容量受最小节点容量的限度。这意味着容量扩大须要对分区从新均衡，这反过来又须要从新复制整个分区，以均衡新增加的代理的数据和流量。从新传输数据十分低廉且容易出错，并且会耗费网络带宽和 I /O。保护人员在执行此操作时必须十分小心，以防止毁坏生产零碎。

Kafka 中分区数据的从新拷贝不仅产生在以分区为核心的零碎中的群集扩大上。许多其余事件也会触发数据从新拷贝，例如正本故障，磁盘故障或计算机的故障。在数据从新复制期间，分区通常不可用，直到数据从新复制实现。例如，如果您将分区配置为存储为 3 个正本，这时，如果失落了一个正本，则必须从新复制残缺个分区后，分区才能够再次可用。

在用户遇到故障之前，通常会疏忽这种缺点，因为许多状况下，在短时间内仅是对内存中缓存数据的读取。当数据被保留到磁盘后，用户将越来越多地不可避免地遇到数据失落，故障复原的问题，特地是在须要将数据长时间保留的场合。

相同，在 Apache Pulsar 中，同样是以分区为逻辑单元，然而以 Segment 为物理存储单元。分区随着工夫的推移会进行分段，并在整个集群中平衡散布，旨在无效地迅速地扩大。

Pulsar 是以 Segment 为核心的，因而在扩大容量时不须要数据从新均衡和拷贝，旧数据不会被从新复制，这要归功于在 Apache BookKeeper 中应用可扩大的以 Segment 为核心的分布式日志存储系统。

通过利用分布式日志存储，Pulsar 能够最大化 Segment 搁置选项，实现高写入和高读取可用性。例如，应用 BookKeeper，正本设置等于 2，只有任何 2 个 Bookie 启动，就能够对主题分区进行写入。对于读取可用性，只有主题分区的正本集中有 1 个处于活动状态，用户就能够读取它，而不会呈现任何不统一。

总结

总之，Apache Pulsar 这种独特的基于分布式日志存储的以 Segment 为核心的公布 / 订阅音讯零碎能够提供许多劣势，例如牢靠的流式零碎，包含无限度的日志存储，无需分区从新均衡的即时扩大，疾速复制修复以及通过最大化数据搁置实现高写入和读取可用性选项。

在这篇文章中，咱们给出了 Apache Pulsar 的架构概述。与其余流式消息传递零碎相比，Apache Pulsar 中的分层架构和以分段为核心的设计是两个独特的设计理念。心愿读者能从架构角度和开发人员的角度更好地理解 Apache Pulsar，并且能理解 Apache Pulsar 和 Apache Kafka 之间的差别。

如果对 Pulsar 感兴趣，可通过下列形式参加 Pulsar 社区：

• Pulsar Slack 频道：https://apache-pulsar.slack.c…
• Pulsar 邮件列表: http://pulsar.incubator.apach…

无关 Apache Pulsar 我的项目的惯例信息，请拜访官网：http://pulsar.incubator.apach… 此外也可关注 Twitter 帐号 @apache_pulsar。