apache pulsar 管理界面(国内哪些公司在使用apachepulsar)

今天跟大家聊聊Apache Pulsar的系统架构和设计理念，可能很多人都不太懂。为了让大家更好的了解，边肖为大家总结了以下内容，希望大家能从这篇文章中有所收获。

我们将介绍Apache Pulsar背后的一些系统架构和设计理念，最后和Apache Kafka的架构做一些比较。

Pulsar的分层架构

Apache Pulsar和其他消息传递系统之间最根本的区别是分层架构。Apache Pulsar集群由两层组成：无状态服务层，由一组接收和传递消息的Broker组成；而有状态持久层，由一组名为bookies的Apache BookKeeper存储节点组成，可以持久存储消息。下图显示了Apache Pulsar的典型部署。

Pulsar客户端提供了生产者-消费者接口，应用程序使用Pulsar客户端连接到Broker来发布和消费消息。

脉冲星客户端不直接与存储层Apache BookKeeper交互。客户端也没有动物园管理员的直接访问权限。这种隔离为Pulsar实现安全的多租户统一认证模型提供了基础。

Apache Pulsar以多种语言为客户端提供支持，包括Java、C、Python、Go和Websockets。

Apache Pulsar还提供了一套兼容卡夫卡的API。用户只需更新依赖关系，将客户端指向脉冲星集群，就可以迁移现有的卡夫卡应用程序，这样现有的卡夫卡应用程序就可以立即与Apache脉冲星一起使用，而无需更改任何代码。

Broker层--无状态服务层

代理集群在Apache Pulsar中形成无状态服务层。服务层是“无状态的”，因为代理实际上并不在本地存储任何消息数据。关于脉冲星主题的新闻存储在分布式日志存储系统(Apache BookKeeper)中。我们将在下一节详细讨论簿记员。

Pulsar将每个主题分区分配给一个代理，该代理被称为主题分区的所有者。脉冲星生产者和消费者连接到主题分区的所有者代理，向所有者代理发送消息并消费消息。

如果代理失败，Pulsar会自动将其拥有的主题分区移动到集群中剩余的可用代理之一。这里要说的一点是，由于Brokers是无状态的，所以在进行Topic迁移时，Pulsar只是将所有权从一个broker转移到另一个broker，在这个过程中不会发生数据复制。

下图显示了一个具有4个代理的脉冲星集群，其中4个主题分区分布在4个代理中。每个代理都拥有并提供主题分区的消息服务。

BookKeeper层--持久化存储层

簿记员是阿帕奇脉冲星的持久存储层。Apache Pulsar中的每个主题分区本质上都是存储在Apache BookKeeper中的分布式日志。

每个分布式日志都被分成段段。每个段作为Apache BookKeeper中的一个分类帐，均匀分布并存储在BookKeeper集群中的多个登记者(Apache BookKeeper的存储节点)中。

细分市场的创建机会包括：基于配置的细分市场规模；基于配置的滚动时间；或者当段的所有者被切换时。

通过分段，主题分区中的消息可以均匀地分布在集群中的所有Bookie中。这意味着主题分区的大小不仅受一个节点的容量限制；相反，它可以扩展到整个簿记员集群的总容量。

下图说明了一个分成x个Segment段的主题分区。每个细分市场存储3份。所有的段被分配和存储在四个庄家。

Segment为中心的存储

存储的分层架构和以段为中心的存储是Apache Pulsar(使用Apache BookKeeper)的两个关键设计概念。这两个基础是Puls。

ar提供了许多重要的好处：

• 无限制的主题分区存储

• 即时扩展，无需数据迁移

• 无缝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的系统架构及设计理念是什么有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注行业资讯频道，感谢大家的支持。