Pulsar 架构概览

Pulsar 架构概览

目录

概览

从顶层视角,一个 Pulsar 实例由一个或多个实例 Puslar 集群组成。一个实例中的多个集群的数据是可以复制的。

一个或多个brokers可以处理与负载均衡producer发送的消息,分发消息到consumers,与配置存储中心 Global ZooKeeper 进行通信,来协调多个任务,存储消息到 BookKeeper 实例中。

一个BookKeeper 集群包含一个或多个 bookies 来持久化存储消息。

一个 ZooKeeper 集群用来在多个 Puslar 集群之间协调任务处理。

配置信息存储与协调任务在多个clusters之间。


Brokers

message broker 是一个无状态组件,主要职责包含两部分:

一个是 HTTP server ,为管理任务提供了 REST API 与生产者消费者提供主题查找服务。生产者联系到broker 发布消息,消费者联系到 brokers 消费消息。

作为一个分发器,是一个使用自定义二进制协议进行数据异步传输的 TCP server。

为了提升性能,消息都是通过 managed ledger 缓存进行分发的,除非积压超过了缓存大小。如果积压增长对内存来说增长的太快,broker将会读取entries 从BookKeeper中读取。

Clusters

一个 Pulsar 实例包含一个或多个Pulsar Clusters。

一个或多个 Pulsar broker。

一个 Zookeeper 团体,作为集群粒度的配置与协调。

作为消息持久化存储的一个bookies 整体。

Metadata store

Puslar 元数据主要维护,Pulsar cluster 信息、topic metadata、schema、borker load 等等。Pulsar 使用 Zookeeper 作为元数据存储,集群配置与协调。

一个 Zookeeper 集群作为 Pulsar metadata 存储与 BookKeeper metadata 存储。

Configuration store

配置存储机制,维护了一个 Pulsar 实例的所有配置,包括 clusters、tenants、namespace、partitioned topic-related 配置。一个 Pulsar 实例可以部署一个本地集群、多个本地集群,也可以部署跨地区集群。一个 Pulsar 实例下多个集群元信息共享。

Persistent storage

Apache BookKeeper

Pulsar 使用 BookKeeper 作为消息持久化存储,BookKeeper 是一个分布式日志先行文件系统,提供了一系列至关优势为 Pulsar

pulsar 可以使用许多独立 logs,被称作 ledgers,随着时间的流失,可以为多个主题创建多个 ledgers 。

顺序数据的实体复制提供了高效存储

报这了多个ledgers 读一致性,即使出现系统错误

提供跨bookies的事件驱动IO

在容量与吞吐量上提供垂直扩展。能力可以迅速扩展通过添加更多bookies的形式

bookies 被设计成并发处理读写请求上千个 ledgers, 可以使用多个硬盘设备,一个用于日志,另一个用于一般存储,bookies 能够隔离写操作延迟对读操作影响。

处理数据消息,游标也被存储在 BookKeeper中,游标为消费组记录订阅位置,BookKeeper 能够使 Pulsar 存储游标以一个扩展的形式。

Ledgers

Ledger是一个只允许追加的数据结构,只有一个写入器,多个 BookKeeper 存储节点(也称为 bookie)都用这个写入器进行写入。 Ledger 的条目会被复制到多个 bookie。 Ledgers 本身仅有非常简单的语义:

Pulsar Broker可以创建ledeger,向 ledger 追加内容到和关闭ledger。

不管是显式关闭还是因为写入器进程崩溃导致的关闭,ledger关闭后只能以只读模式打开,。

最后,当ledger中的条目不再有用的时候,整个 legder 就可以从系统中删除,一个 ledger 删除就相当于从所有 bookie 中删除。

Ledger读一致性

BookKeeper的主要优势在于他能在有系统故障时保证 ledger 读的一致性。 由于Ledger只能被一个进程写入,这样这个进程在写入时不会有冲突,从而写入会非常高效。 在发生故障后,ledger会启动一个恢复进程来确定ledger的最终状态并确认最后提交到日志的是哪一个条目。 在这之后,所有的ledger读进程就能保证读取到相同的内容。

Managed ledgers

由于BookKeeper Ledgers提供了单一的日志抽象,在ledger的基础上我们开发了一个叫managed ledger的库,用以表示单个topic的存储层。 Managed ledger 是消息流的抽象,有一个写入器进程不断在流结尾添加消息,并且有多个 cursors 消费这个流,每个cursor 有与自身关联的消费位置。

内部实现中,单个 managed ledger 使用了多个 BookKeeper ledger 来存储数据,使用多个 ledger 主要有两个原因:

在故障之后,原有的ledger不能再写了,这时需要创建一个新的 ledger。

当所有 cursor 消费完一个 ledger 包含的消息后,ledger 会被删除。 这样可以周期性的滚动使用 ledger。

Journal 存储

BookKeeper的 journal 文件包含了 BookKeeper 的事务日志。 在更新追加到 ledger 之前,bookie 需要确保描述这个更新的事务被写到持久存储上面。 在 bookie 启动或旧的 journal 文件大小达到上限,新的 journal 文件会被创建。

参考

https://pulsar.apache.org/docs/2.10.x/concepts-architecture-overview

https://mp.weixin.qq.com/s/CIpCLCxqpLoQVUKz6QeDJQ

https://alexstocks.github.io/html/pulsar.html

你可能感兴趣的:(Pulsar 架构概览)