Pulsar 核心组件原理

天微微蓝sunny

于 2024-07-21 18:09:33 发布

阅读量945

点赞数 26

CC 4.0 BY-SA版权

分类专栏： Pulsar 文章标签：中间件

本文链接：https://blog.csdn.net/Tianweilan123/article/details/140591363

Pulsar 专栏收录该内容

5 篇文章

订阅专栏

Pulsar 核心组件原理

1、Pulsar 设计概要
2、Broker 原理
3、Bookie 原理
4、多租户设计
5、当前 Pulsar 面临的挑战

1、Pulsar 设计概要

随着技术的进步，网络速度越来越快，不再是分布式系统的瓶颈，而计算机磁盘I/0速度增长相对缓慢，计算和存储混合的架构缺点随之逐渐显现（比如 Kafka 扩缩容困难等）。

Pulsar 就是在这样的背景下设计的，存算分离，服务端 Broker 节点只负责计算，Bookie 节点只负责存储数据，Broker 和 Bookie 可分别支持扩缩容。存算分离带来的优势就是云原生友好，支持扩缩容以提高资源利用率。
在这里插入图片描述

上图演示了生产者写入一条消息的过程，客户端与主题归属的 Broker 连接并发起写请求，Broker 作为 Bookie 的 Client，将数据写入存放主题数据对应的 Bookie 节点，存储多个副本以保证可靠性。Ledger 是 Bookie 内部数据的组织逻辑。

Pulsar 自动扩缩容的挑战主要有：如何识别过载和空闲的 Broker ，识别出来以后需要做 topic 归属 Broker 的重新划分，要保证不影响已有的客户端连接。

2、Broker 原理

Pulsar 的 topic 会均匀分布到所有 Broker 上，扩容后，是否会自动负载均衡，是关键。

在Broker层面，Pulsar 引入了 Namespace Bundle 概念，每个 Namespace 被划分为多个 Bundle，以实现计算资源的分片和隔离。

Topic 通过名称计算哈希值，并散列分布到一致性哈希环中，而哈希环的每一段都是一个 Bundle。另外 Load Manager 根据 Bundle 的负载情况将后者分配到对应的 Broker 上，将 Bundle 数据存储在 ZooKeeper 中。由此以来就间接实现了 Topic 与 Broker 之间的联系。

Broker 负载均衡的基本单位是 Bundle。

在多个Broker节点中存在一个主节点(Leader Broker)。主节点主要有两个职责：周期性地获取各个Broker节点的负载情况，根据负载情况周期性地执行任务负载均衡任务。

Broker 节点还提供节点减载与命名空间包切分两种方式来做负载均衡。节点减载就是把繁忙的 Broker 上的部分 Bundle 划分到其他 Broker 上以降低计算压力。命名空间包切分就是把一个繁忙的 Bundle 切分称多个小的 Bundle，再把小的 Bundle 分配到其他 Broker 上。

在 Broker 对应的 Bundle 需要迁移时，当前 Broker 会暂时关闭主题和客户端会话，并将所有权转移给选定的 Broker。

Pulsar 客户端写副本的模式不同于 Kafka 为服务端 Broker 主动从其他节点同步副本数据，Pulsar 客户端会同时向副本所在的多个服务端发起写请求，Bookie（BookKeeper）中由最后添加协议(LastAddConfirmed, LAC)实现可重复读取的一致性保证。

3、Bookie 原理

Bookie 是负责存储数据的。Bookie 也支持轻松的扩缩容，这和底层的数据结构是密不可分的。

Pulsar 的每个主题都是逻辑主题，即主题只是逻辑上的一个概念，物理上不同主题的数据存储在同一个 Ledger 文件中。

Pulsar 会把一段时间内生产的数据写入同一个 Ledger 文件中，当条数/大小到达一定数量后，滚动新的 Ledger 文件。Bookie 中的 Ledger 在集群中的所有 bookie 之间保持平衡。当某个 bookie 的存储容量耗尽时，其余段将加载到可用的 Bookie 中。

Bookie 节点中的数据写入示意图如下，1. 客户端数据写入 Journal 内存。2. 将 Journal 数据刷写到 Journal 磁盘（Journal 数据相当于 WAL 日志，用于做故障恢复）。3. 将 Journal 数据写入 Bookie 内存表。4. 写入完成。
在这里插入图片描述

其中，Journal 文件实时刷盘，采用SSD刷盘，可以达到约 0.4 毫秒的 fsync 延迟。

Bookie 内存表中的数据采用异步刷盘的方式，刷写到 Ledger 磁盘，实现数据持久化。

内存索引主要是区分 Ledger 上所属于不同 topic 的数据。

读取 BookKeeper（Bookie）中的数据示意图如下，先从 Bookie 内存表读取数据（称为追尾读，效率高），当读取的数据较早在 Bookie 内存表中没读取到时，就需要从磁盘读取（追赶读）。

在这里插入图片描述

在进行追赶读时，服务端需要从 Ledger 磁盘中读取数据，此时 Journal 磁盘不会受读取请求的影响。因此在 BookKeeper 的生产环境中，将多个磁盘设备挂载在一个 Bookie 系统，通过合理的配置即可获取读写I/O分离的特性。

4、多租户设计

Pulsar 的多租户设计，除了配额、限流等机制以外，支持硬件资源隔离（即为不同业务分配专属的 Broker 和 Bookie 资源）。Pulsar 资源隔离机制允许用户为命名空间分配资源，包括计算节点Broker和存储节点Bookie。pulsar-admin管理工具提供了ns-isolation-policy命令，该命令可以为命名空间分配Broker节点，并限制可用于分配的Broker。pulsar-admin管理工具的namespaces命令中的set-bookie-affinity-group子命令提供了Bookie节点的分配策略，该策略可以保证所有属于该命名空间的数据都存储在所需的Bookie节点中。