本文最后公布于 DataStax 官网博客，经原作者受权由 InfoQ 中文站翻译并分享。本译文公布也已取得受权，较原文有调整。
译文链接：https://www.infoq.cn/article/…

对于 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 分层分片架构

欢送关注 Apache Pulsar 中文社区公众号 ApachePulsar，获取最新 Apache Pulsar 动静与技术干货。