关于apache:博文推荐|Apache-Pulsar-轻装上阵迈向轻-ZooKeeper-时代

10次阅读

共计 3926 个字符,预计需要花费 10 分钟才能阅读完成。

本文翻译自《Pulsar Isolation Part III: Separate Pulsar Clusters Sharing a Single BookKeeper Cluster》,原文链接:https://streamnative.io/blog/…。作者 David Kjerrumgaard,Apache Pulsar Committer,StreamNative 布道师。

译者简介

李文奇,就任于微软 STCA,业余时间喜爱钻研各类中间件技术及分布式系统。

首次!无 ZooKeeper 也能运行 Pulsar

Apache Pulsar™ 有时被视为一个较简单的零碎,有一部分起因是因为 Pulsar 应用了 Apache ZooKeeper™ 存储元数据。从设计之初,Plusar 就应用 ZooKeeper 存储调配给 topic 的 broker 信息、topic 的平安和数据留存策略等要害元数据信息。ZooKeeper 这个额定组件便加深了大家对于 Pulsar 是一个简单零碎的印象。

为了简化 Pulsar 的部署,社区发动了一项打算——Pulsar 改良布局 PIP-45 来加重对 ZooKeeper 的依赖,同时用可插拔的框架来代替。这种可插拔的框架反对用户依照理论的部署环境抉择可替换的元数据及协调系统,从而缩小了 Pulsar 在基础设施层面的必须依赖。

PIP- 45 的实现与将来打算

PIP-45 的代码曾经被提交到了主分支上,并行将于 Pulsar 2.10 版本公布。Apache Pulsar 用户首次能够在没有 ZooKeeper 的状况下运行 Pulsar。

与 Apache Kafka 的 ZooKeeper 替换策略不同,PIP-45 的目标不是内部化 Apache Pulsar 平台自身的分布式协调性能。相同,它容许用户依据本身环境选用适合的技术组件来替换 ZooKeeper。

在非生产环境中,当初用户能够抉择应用轻量级的代替计划,可将元数据保留在内存中或者本地磁盘上。开发人员便可收回之前在其笔记本上运行 Apache ZooKeeper 所需的计算资源。

在生产环境中,Pulsar 的可插拔框架反对用户利用那些早已在本身软件技术栈中运行的组件作为 ZooKeeper 的代替计划。

能够设想,如此重大的打算由多个步骤组成,目前其中一些曾经实现。本文将带您浏览迄今为止已实现的步骤(步骤 1-4),并概述仍须要实现的工作(步骤 5-6)。请留神,本文中探讨的性能尚处于测试阶段,在理论公布版本中可能会有所变动。

第一步:定义元数据存储 API

PIP-45 为元数据管理和分布式协调提供了一个跨技术组件的接口,从而容许应用非 ZooKeeper 的形式治理元数据等,减少了零碎的灵活性。

ZooKeeper 客户端 API 从来贯通整个 Apache Pulsar 代码库,因而咱们首先须要通过单个通用的 MetadataStore 接口来整合所有这些 API 调用。该接口的结构是基于 Pulsar 在与元数据间交互的需要以及一些由现有的元数据贮存引擎(如 ZooKeeper 及 etcd)提供的场景语义。


图 1:反对开发不同的 MetadataStore 接口实现形式,从而用接口来代替对 Apache ZooKeeper 的间接依赖,并提供了用户依据本身环境选用的灵活性。

这一步不仅将 Pulsar 与 ZooKeeper API 进行理解耦,同时也构建了一种可插拔框架,这样不同的接口实现便能在开发环境中相互替换。

这些新接口容许 Pulsar 用户依据 broker 配置文件中的 metadataURL 属性值轻松地将 Apache ZooKeeper 替换为其余元数据管理系统或其余协调服务。这套框架会依据 URL 的前缀主动产生正确的实例。例如,如果 metadataURL 配置属性值以 Rocksdb:// 结尾,则将应用 RocksDB 作为接口的实现。

第二步:创立基于 ZooKeeper 的实现

一旦定义了这些接口,会创立一个基于 Apache ZooKeeper 的默认实现,以便为现有的 Pulsar 平稳过渡到新的可插拔框架。

这一阶段咱们的次要指标是对于那些想保留 Apache ZooKeeper 的用户,避免因 Pulsar 降级到新版本而产生任何重大的变更。因而,咱们须要确保以后存储在 ZooKeeper 中的现有元数据在降级后也能够保留在与以前雷同的地位和雷同的格局中。

基于 ZooKeeper 的实现容许用户持续抉择应用 ZooKeeper 作为元数据存储层,并且在 etcd 版本实现以前,这是目前惟一在生产环境中可用的实现形式。

第三步:创立基于 RocksDB 的实现

在解决了这些向后兼容问题之后,下一步是提供不基于 ZooKeeper 的实现形式,以展现框架的可插拔性。验证该框架的最简略形式是在单机模式(standalone 模式)下基于 RocksDB 实现 MetaDataStore。

这不仅证实该框架具备在不同 MetaDataStore 实现形式切换的能力,同时也能大大减少残缺运行齐全独立的 Pulsar 集群所需的资源总量。该步骤的实现对抉择在本地(通常是 Docker 容器)进行开发和测试的开发者们有间接的影响。

第四步:创立基于内存的实现

缩减元数据存储也对单元与集成测试大有裨益。咱们发现,MetaDataStore 的内存实现更加适宜测试场景,这就缩小了重复启动 ZooKeeper 集群以执行一套测试而后将其敞开的老本。

同时,不仅可能缩小运行 Pulsar 全套集成测试所需的资源量,而且还可能缩小测试的工夫。

通过利用 MetaDataStore 的内存实现,Pulsar 我的项目的构建和公布周期将会大大缩减,构建、测试和公布也可能更快地变更到社区。

第五步:创立基于 Etcd 的实现

鉴于 Pulsar 云原生的设计架构,ZooKeeper 最显著的替代者便是 etcd。etcd 是一致性、高可用的键值存储系统,用作 Kubernetes 的所有集群元数据的存储。

除了其社区不断扩大且沉闷,我的项目的宽泛应用,以及性能和可扩展性的改良之外,作为管制面的一部分,etcd 早已在 Kubernetes 中可用。因为 Pulsar 人造反对在 Kubernetes 内运行,在大多数生产环境中都能够间接拜访到运行的 etcd 实例,因而用户能够间接应用已有的 etcd,而不会额定减少 ZooKeeper 带来更多经营老本。


图 2: 当在 Kubernetes 中运行 Pulsar 时,用户能够应用已有的 etcd 实例来简化部署

利用在 Kubernetes 集群内运行的现有 etcd 服务来作为元数据存储,用户能够齐全不须要运行 ZooKeeper。这不仅缩小了 Pulsar 集群的基础设施占用的资源,还加重了运行和操作简单的分布式系统所需的经营累赘。

etcd 的所带来的性能晋升是一项令人特地兴奋的技术停顿——etcd 旨在解决与 ZooKeeper 相干的一些问题。对于初学者来说,etcd 齐全是用 Go 编写的,ZooKeeper 次要是用 Java 编写的,而 Go 通常被认为是比 Java 性能更高的编程语言。

此外,etcd 应用较新的 Raft 共识算法,该算法在容错和性能方面与 ZooKeeper 应用的 Paxos 算法差异不大。然而,它比 ZooKeeper 应用的 ZaB 协定更容易了解和实现。

etcd 的 Raft 实现与 Kafka(KRaft)实现的最大区别在于后者应用基于拉的模型进行同步更新,在提早上略有劣势。Raft 算法的 Kafka 版本也是用 Java 实现的,它在垃圾回收期间可能会呈现长时间的进展。而在基于 Go 语言的 Raft 算法的 etcd 版本中则没有这个问题。

第六步:缩放元数据层

现在,Pulsar 集群扩大的最大阻碍是元数据层的存储容量。应用 ZooKeeper 存储此元数据时,必须将数据保留在内存中,以提供较好的提早性能。用一句话概括便是 ” 磁盘就是 ZooKeeper 的死穴 ”。

然而,etcd 中的数据存储形式是 B 树数据结构,而不是 ZooKeeper 应用的分层树结构,etcd 所用的数据存储构造存储在磁盘上并映射到内存中以提供低提早的拜访。

这样做的意义在于,它无效地将元数据层的存储容量从内存规模减少到磁盘规模,使咱们可能存储大量的元数据。比照 ZooKeeper 与 etcd,存储容量从 ZooKeeper 的几 G 内存扩大到了超过 100G 的 etcd 磁盘。

装置与更多细节

在过来几年中,Pulsar 成为了最沉闷的 Apache 我的项目之一,正如 PIP-45 我的项目所展现的那样,一个充满活力的社区将持续推动我的项目的翻新和改良。

急不可待想要尝试去 ZooKeeper 的 Pulsar 吗?下载最新版本的 Pulsar,并在独立模式下运行,或者参考文档。

除了去除对 ZooKeeper 的强依赖,Apache Pulsar 2.10.0 版本蕴含来自于 99 位贡献者的 1000 个 commit,引入了多达 300 项重要的更新。行将公布的新版本中还有诸多令人兴奋的技术停顿:

  • 引入 TableView 升高用户构建键值对视图的老本;
  • 在客户端增加多集群主动故障转移策略;
  • 减少音讯重试指数退却提早策略;
  • ……

在上周日的 TGIP-CN 037 直播中,Apache Pulsar PMC 成员,StreamNative 首席架构师李鹏辉为大家介绍了行将公布的 Apache Pulsar 2.10 版本个性,敬请关注本周 Apache Pulsar 公众号推送~

不过能够 扫码 提前浏览回顾视频哟:

参考文献

  • PIP-117: Change Pulsar standalone defaults
  • Apache ZooKeeper vs. etcd3
  • Performance optimization of etcd in web scale data scenario

关注 公众号「ApachePulsar」,获取更多技术干货

退出 Apache Pulsar 中文交换群👇🏻

正文完
 0