关于apache:博文推荐-Apache-Pulsar-对现代数据堆栈至关重要的四个原因

37次阅读

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

对于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级我的项目,是下一代云原生分布式音讯流平台,集音讯、存储、轻量化函数式计算为一体,采纳计算与存储拆散架构设计,反对多租户、长久化存储、多机房跨区域数据复制,具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。\
GitHub 地址:http://github.com/apache/pulsar/

多年来,DataStax 始终关注音讯畛域。一个十分重要的起因是基于微服务的架构日益遍及。简略来说,微服务架构应用音讯总线来解耦服务之间的通信,并简化重放、错误处理和负载峰值。

有了 Cassandra 和 Astra,开发者和架构师就有了这样一个数据库生态系统:

  • 以开源为根底
  • 非常适合混合云和多云部署
  • 云原生,按生产计价

目前还没有满足这些需要的音讯解决方案,因而咱们打算打造一个。从评估最风行的 Apache Kafka 开始,咱们发现它在四个方面存在有余:

  1. 跨地区复制
  2. 扩大
  3. 多租户
  4. 队列

然而,针对 Kafka 的不足之处,Apache Pulsar 却解决了所有这些问题。 让咱们逐项看下 Pulsar 在这四方面的劣势。

Pulsar 反对跨地区复制

Kafka 被设计为在单个区域内运行,不反对跨数据中心的复制。Kafka 部署区域之外的客户端只能忍耐提早减少。有几个我的项目试图在客户端层面向 Kafka 增加跨数据中心的复制,但操作都很艰难,而且容易失败。

Pulsar 在外围服务器上构建了跨地区复制性能,你能够在部署时抉择同步或异步配置,并且能够按主题配置复制机制。生产者能够从任何地区写入共享主题,Pulsar 负责确保这些信息对各地的消费者均可见。

Pulsar 具备高可扩展性

在 Kafka 中,存储单元是一个段文件,然而复制单元是一个分区中的所有段文件。每个分区都归一个 leader 代理所有,它会复制给多个 follower。所以,当你须要给 Kafka 集群减少容量时,在新节点分担现有节点的负载之前,有些分区须要复制到新节点上。

这意味着,减少 Kafka 集群的容量会使其变慢,而不是变快。如果你的容量布局恰到好处,这很好,但如果业务需要的变动比你预期的要快,那么这可能会是一个重大的问题。

Pulsar 减少了一个间接层。(Pulsar 也将计算和存储离开,别离由 broker 和 bookie 治理,但这里,最重要的局部是 Pulsar 如何通过 BookKeeper 减少复制的粒度。)在 Pulsar 中,分区被宰割成 ledger,但和 Kafka 段不同,ledger 能够独自复制,互不影响。Pulsar 在 ZooKeeper 中保护着一个 ledger 到分区的映射。因而,当咱们向集群增加一个新的存储节点时,咱们所要做的就是在该节点上启动一个新的 ledger。现有的数据能够保留在原来的地位,不须要集群做额定的工作。

要深刻理解 Pulsar 的架构和存储模型,请浏览 Jack Vanlightly 的博文。

Pulsar 反对多租户

多租户基础设施能够跨多个用户和组织共享,同时保障它们彼此隔离。一个租户的流动不应该影响其余租户的平安或 SLA。

从根本上说,多租户能够从两个方面降低成本。首先,简略地共享单个租户没有充分利用的基础设施——将组件的老本摊派到所有用户。第二,通过简化治理——当有几十、几百或几千个租户时,治理一个实例显著简略许多。即便在一个容器化的世界里,“在这样一个共享零碎上给我调配一个帐户”也比“为我提供这个服务的一个新实例”容易实现得多。全球性的问题可能因为扩散在许多实例中而被覆盖。

与跨地区复制一样,多租户很难移植到没有这项设计的零碎上。Kafka 是单租户设计,但 Pulsar 从内核上就反对多租户。

Pulsar 容许咱们通过一个接口治理跨多个区域的多个租户,该接口包含身份验证和受权、隔离策略(Pulsar 能够抉择在集群中划分出专供单个租户应用的硬件)和存储配额。

Pulsar 反对队列(也反对流)

Kafka 提供了一个经典的公布 / 订阅(publish/subscribe)音讯模型——发布者发送音讯给 Kafka,后者在主题中按分区排序,并给每个订阅者(或”消费者“)发送一份正本。

Kafka 用日志中的偏移量记录消费者曾经看到了哪条音讯。这意味着音讯不能乱序确认,同时也意味着不能跨多个消费者共享订阅。(在其消费者分组设计中,Kafka 容许将多个分区映射到一个消费者,但不能反过来。)

这对于公布 / 订阅用例(有时称为流)来说很好。对于流,重要的是要以与音讯公布时雷同的程序生产音讯。

Pulsar 反对公布 / 订阅模式,但也反对队列模式,在后一种状况下,解决程序并不重要,咱们只想在任意数量的消费者之间均衡一个主题的音讯:

这(以及面向队列的个性,如“死信队列”和反对从新发送的否定确认)意味着 Pulsar 常常能够取代 AMQP 和 JMS 以及 Kafka 格调的公布 / 订阅,采纳 Pulsar 的企业有机会进一步降低成本。

小结

与 Kafka 相比,Pulsar 的架构使它在跨地区复制、扩大、多租户和队列等方面具备重要的劣势。近日,DataStax 也发表退出到 Pulsar 社区,推动 Pulsar 成长和倒退。

相干浏览

  • 了解 Apache Pulsar 工作原理
  • Apache Pulsar Pulsar 的跨地区复制机制介绍 (1)”)
  • Apache Pulsar Pulsar 的跨地区复制机制介绍 (2)”)
  • Pulsar vs Kafka 对立生产模型
  • Pulsar vs Kafka 分层分片架构

点击 链接,查看原文。

正文完
 0