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中不会涉及到不必要的数据搬迁，不会将旧数据从现有存储节点重新复制到新存储节点。