共计 5254 个字符，预计需要花费 14 分钟才能阅读完成。
Apache Pulsar 是一个多租户、高性能的服务间音讯传输解决方案，数据长久化依赖 Apache BookKeeper 实现，反对多租户、低延时、读写拆散、跨地区复制、疾速扩容、灵便容错等个性。本文将从以下几个方面为大家介绍 Apache Pulsar 的设计原理和个性。
1、Apache Pulsar 架构
2、架构设计的劣势
3、Pulsar 个性
4、总结
Apache Pulsar 架构
存储计算拆散
Apache Pulsar 是 Pub/Sub 模型的音讯零碎，并且从设计上做了存储和计算的拆散，如图一所示。
图一 Pulsar 架构
Apache Pulsar 次要包含 Broker, Apache BookKeeper, Producer, Consumer 等组件。
- Broker：无状态服务层，负责接管和传递音讯，集群负载平衡等工作，Broker 不会长久化保留元数据，因而能够疾速的上、下线。
- Apache BookKeeper：有状态长久层，由一组名为 Bookie 的存储节点组成，长久化地存储音讯。
- Producer：数据生产者，负责公布数据到 Topic。
- Consumer：数据消费者，负责从 Topic 订阅数据。
除了上述的组件之外，Apache Pulsar 还依赖 Zookeeper 作为元数据存储。与传统的音讯零碎相比，Apache Pulsar 在架构设计上采纳了计算与存储拆散的模式，Pub/Sub 相干的计算逻辑在 Broker 上实现，数据存储在 Apache BookKeeper 的 Bookie 节点上。
分片存储
除了存储、计算解耦拆散的设计之外，Apache Pulsar 在存储设计上也不同于传统 MQ 的分区数据本地存储的模式，采纳的是分片存储的模式，存储粒度比分区更细化、存储负载更平衡。Apache Pulsar 中的每个 Topic 分区实质上都是存储在 Apache BookKeeper 中的分布式日志。Topic 能够有多个分区，分区数据长久化时，分区是逻辑上的概念，理论存储的单位是分片（Segment）的，如图二，一个分区 Topic1-Part2 的数据由多个 Segment 组成，每个 Segment 作为 Apache BookKeeper 中的一个 Ledger，均匀分布并存储在 Apache BookKeeper 群集中的多个 Bookie 节点中，每个 Segment 具备 3 个正本。
图二 Pulsar 分片存储
上面能够通过图三来看分区和分片存储的区别。
图三 分片存储和分区存储
架构设计的劣势
Apache Pulsar 计算与存储拆散的架构，以及分片存储的设计为 Apache Pulsar 带来了相比于传统基于分区存储 MQ 的一些劣势：
- Broker 和 Bookie 互相独立，不便实现独立的扩大以及独立的容错。
- Broker 无状态，便于疾速上、下线，更加适宜于云原生场景。
- 分区存储不受限于单个节点存储容量。
- 分区数据分布平均。
- …
可扩展性
因为音讯服务层和长久存储层是离开的，因而 Apache Pulsar 能够独立地扩大存储层和服务层。
Broker 扩大
在 Pulsar 中 Broker 是无状态的，能够通过减少节点的形式实现疾速扩容。当须要反对更多的消费者或生产者时，能够简略地增加更多的 Broker 节点来满足业务需要。Pulsar 反对主动的分区负载平衡，在 Broker 节点的资源使用率达到阈值时，会将负载迁徙到负载较低的 Broker 节点，这个过程中分区也将在多个 Broker 节点中做均衡迁徙，一些分区的所有权会转移到新的 Broker 节点。
Bookie 扩大
存储层的扩容，通过减少 Bookie 节点来实现。通过资源感知和数据搁置策略，流量将主动切换到新的 Bookie 节点中，整个过程不会波及到不必要的数据搬迁，即不须要将旧数据从现有存储节点从新复制到新存储节点。
图四 Bookie 扩容
如图四所示，起始状态有四个存储节点，Bookie1, Bookie2, Bookie3, Bookie4，以 Topic1-Part2 为例，当这个分区的最新的存储分片是 SegmentX 时，对存储层扩容，增加了新的 Bookie 节点，BookieX,BookieY，那么在存储分片滚动之后，新生成的存储分片，SegmentX+1,SegmentX+2，会优先选择新的 Bookie 节点（BookieX,BookieY）来保留数据。
容错
得益于计算与存储拆散以及分片存储的设计，Pulsar 能够实现独立、灵便的容错。
Broker 容错
当 Broker 节点失败时，以图五为例，当存储分片滚动到 SegmentX 时，Broker2 节点失败，此时生产者和消费者向其余的 Broker 发动申请，这个过程会触发分区的所有权转移，行将 Broker2 领有的分区 Topic1-Part2 的所有权转移到其余的 Broker(Broker3)。在 Apache Pulsar 中数据存储和数据服务拆散，所以新 Broker 接管分区的所有权时，它不须要复制 Partiton 的数据。新的分区 Owner（Broker3）会产生一个新的分片 SegmentX+1, 如果有新数据到来，会存储在新的分片 Segment x+ 1 上，不会影响分区的可用性。
图五 Broker 容错
Bookie 容错
当 Bookie 节点失败时，如图六所示，假如 Bookie 2 上的 Segment 4 损坏。Apache BookKeeper Auditor 会检测到这个谬误并进行复制修复。Apache BookKeeper 中的正本修复是 Segment 级别的多对多疾速修复，BookKeeper 能够从 Bookie 3 和 Bookie 4 读取 Segment 4 中的音讯，并在 Bookie 1 处修复 Segment 4。如果是 Bookie 节点故障，这个 Bookie 节点上所有的 Segment 会依照上述形式复制到其余的 Bookie 节点。所有的正本修复都在后盾进行，对 Broker 和利用通明，Broker 会产生新的 Segment 来解决写入申请，不会影响分区的可用性。
图六 Bookie 容错
无限度的分区存储
分片存储解决了分区容量受单节点存储空间限度的问题，当容量不够时，能够通过扩容 Bookie 节点的形式撑持更多的分区数据，也解决了分区数据歪斜问题，数据能够平均的调配在 Bookie 节点上。Broker 和 Bookie 灵便的容错以及无缝的扩容能力让 Apache Pulsar 具备十分高的可用性。
Pulsar 个性
基于上述的设计特点，Pulsar 提供了很多个性，以下做简要的介绍。
读写拆散
Pulsar 另外一个有吸引力的个性是提供了读写拆散的能力，读写拆散保障了在有大量滞后生产（磁盘 IO 会减少）时，不会影响服务的失常运行，尤其是不会影响到数据的写入。读写拆散的能力由 Apache BookKeeper 提供，简略说一下 Bookie 存储波及到的概念：
- Journals：Journal 文件蕴含了 BookKeeper 事务日志，在 Ledger 更新之前，Journal 保障形容更新的事务写入到 Non-volatile 的存储介质上。
- Entry logs：Entry 日志文件治理写入的 Entry，来自不同 ledger 的 entry 会被聚合而后程序写入。
- Index files：每个 Ledger 都有一个对应的索引文件，记录数据在 Entry 日志文件中的 Offset 信息。
Entry 的读写入过程如图七所示，数据的写入流程：
- 数据首先会写入 Journal，写入 Journal 的数据会实时落到磁盘。
- 而后，数据写入到 Memtable，Memtable 是读写缓存。
- 写入 Memtable 之后，对写入申请进行响应。
- Memtable 写满之后，会 Flush 到 Entry Logger 和 Index cache，Entry Logger 中保留了数据，Index cache 保留了数据的索引信息，而后由后盾线程将 Entry Logger 和 Index cache 数据落到磁盘。
数据的读取流程：
- 如果是 Tailing read 申请，间接从 Memtable 中读取 Entry。
- 如果是 Catch-up read（滞后生产）申请，先读取 Index 信息，而后索引从 Entry Logger 文件读取 Entry。
图七 Bookie 的数据写入和读取
个别在进行 Bookie 的配置时，会将 Journal 和 Ledger 存储磁盘进行隔离，缩小 Ledger 对于 Journal 写入的影响，并且举荐 Journal 使用性能较好的 SSD 磁盘，读写拆散次要体现在：
- 写入 Entry 时，Journal 中的数据须要实时写到磁盘，Ledger 的数据不须要实时落盘，通过后盾线程批量落盘，因而写入的性能次要受到 Journal 磁盘的影响。
- 读取 Entry 时，首先从 Memtable 读取，命中则返回；如果不命中，再从 Ledger 磁盘中读取，所以对于 Catch-up read 的场景，读取数据会影响 Ledger 磁盘的 IO，对 Journal 磁盘没有影响，也就不会影响到数据的写入。
所以，数据写入是次要是受 Journal 磁盘的负载影响，不会受 Ledger 磁盘的影响。另外，Segment 存储的多个正本都能够提供读取服务，相比于主从正本的设计，Apache Pulsar 能够提供更好的数据读取能力。通过以上剖析，Apache Pulsar 应用 Apache BookKeeper 作为数据存储，能够带来下列的收益：
- 反对将多个 Ledger 的数据写入到同一个 Entry logger 文件，能够防止分区收缩带来的性能降落问题。
- 反对读写拆散，能够在滞后生产场景导致磁盘 IO 上升时，保证数据写入的不受影响。
- 反对全副本读取，能够充分利用存储正本的数据读取能力。
多种生产模型
Apache Pulsar 提供了多种订阅形式来生产音讯，分为三种类型：独占（Exclusive），故障切换（Failover）或共享（Share）。
图八 生产模型
- Exclusive 独占订阅 ：在任何工夫，一个消费者组（订阅）中有且只有一个消费者来生产 Topic 中的音讯。
- Failover 故障切换 ：多个消费者（Consumer）能够附加到同一订阅。然而，一个订阅中的所有消费者，只会有一个消费者被选为该订阅的主消费者。其余消费者将被指定为故障转移消费者。当主消费者断开连接时，分区将被重新分配给其中一个故障转移消费者，而新调配的消费者将成为新的主消费者。产生这种状况时，所有未确认（ack）的音讯都将传递给新的主消费者。
- Share 共享订阅 ：应用共享订阅，在同一个订阅背地，用户依照利用的需要挂载任意多的消费者。订阅中的所有音讯以循环散发模式发送给订阅背地的多个消费者，并且一个音讯仅传递给一个消费者。当消费者断开连接时，所有传递给它然而未被确认（ack）的音讯将被重新分配和组织，以便发送给该订阅上残余的残余消费者。
多种 ACK 模型
音讯确认（ACK）的目标就是保障当产生故障后，消费者可能从上一次进行的中央复原生产，保障既不会失落音讯，也不会反复解决曾经确认（ACK）的音讯。在 Pulsar 中，每个订阅中都应用一个专门的数据结构 – 游标（Cursor）来跟踪订阅中的每条音讯的确认（ACK）状态。每当消费者在分区上确认音讯时，游标都会更新。Pulsar 提供两种音讯确认办法：
- 单条确认（Individual Ack），独自确认一条音讯。被确认后的音讯将不会被从新传递。
- 和累积确认（Cumulative Ack），通过累积确认，消费者只须要确认它收到的最初一条音讯。
图九阐明了单条确认和累积确认的差别（灰色框中的音讯被确认并且不会被从新传递）。对于累计确认，M12 之前的音讯被标记为 Acked。对于独自进行 ACK，仅确认音讯 M7 和 M12，在消费者失败的状况下，除了 M7 和 M12 之外，其余所有音讯将被从新传送。
图九 ACK 模型
跨地区复制
Apache Pulsar 的跨地区复制机制（Geo-Replication）提供了一种全连贯的异步复制，能够满足多个数据中心数据同步的应用场景。
图十 Geo-replication
如图十所示，有三个 Apache Pulsar 集群，散布于北京、上海和广州，用户创立的一个 Topic T1 设置了逾越三个数据中心做互备。在三个数据中心中，别离有三个生产者：P1、P2、P3，它们往主题 T1 中公布音讯；有两个消费者：C1、C2，订阅了这个主题，接管主题中的音讯。当音讯由本数据中心的生产者公布胜利后，会立刻复制到其余两个数据中心。音讯复制实现后，消费者不仅能够收到本数据中心产生的音讯，也能够收到从其余数据中心复制过去的音讯。
总结
Pulsar 采纳了计算、存储拆散的设计，并且存储在逻辑上分区，物理上分片，具备一些传统类 kafka 的 MQ 所不具备的劣势，也解决了一些业界的痛点，Pulsar 目前社区比拟沉闷，还处于疾速倒退的阶段，除了以上的个性之外，Pulsar 还能够反对事务、SQL 查问、Function 等性能，另外 Pulsar 反对 protocol handler，比方 KoP（Kafka on Pulsar）, 能够原生反对 Kafka 协定的数据，对于这些个性，咱们会在后续的文章中做介绍。
