原创：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。