Apache Pulsar 对现代数据堆栈至关重要的几个原因.docxVIP

Apache Pulsar 对现代数据堆栈至关重要的几个缘由 Cassandra 支持数据中心内或跨数据中心的同步和异步复制。（通常，Cassandra 被配置为区域内的同步复制，以及跨区域的异步复制。）这使得像Netflix这样的Cassandra用户可以为各地的客户供应低延迟的服务，恪守数据主权规定，并且可以经受住基础设备毛病。（ 当 AWS 需要重启 218 个 Cassandra 节点修补一个平安漏洞时，“Netflix经受了0宕机”。） Kafka 被设计为在单个区域内运转，不支持跨数据中心的复制。Kafka 部署区域之外的客户端只能忍耐延迟添加。有几个项目试图在客户端层面对 Kafka 添加跨数据中心的复制，但操作都很困难，而且简约失败。 和 Cassandra 一样，Pulsar 在核心服务器上构建了跨地域复制功能。（也像 Cassandra 一样，你可以在部署时选择同步或异步配置，并且可以按主题配置复制机制。）生产者可以从任何地区写入共享主题，Pulsar 担任确保这些信息对各地的消费者均可见。 - 扩展 - 在 Kafka 中，存储单元是一个段文件，但是复制单元是一个分区中的全部段文件。每个分区都归一个 leader 代理全部，它会复制给多个 follower。所以，当你需要给 Kafka 集群添加容量时，在新节点分担现有节点的负载之前，有些分区需要复制到新节点上。 ?这意味着，添加 Kafka 集群的容量会使其变慢，而不是变快。假如你的容量规划恰到好处，这很好，但假如业务需求的变化比你预期的要快，那么这可能会是一个严峻的问题。 Pulsar 添加了一个间接层。（Pulsar 也将计算和存储分开，分别由 broker 和 bookie 管理，但这里，最重要的部分是 Pulsar 如何通过 Bookkeeper 添加复制的粒度。）在 Pulsar 中，分区被分割成 ledger，但和 Kafka 段不同，ledger 可以单独复制，互不影响。Pulsar 在 Zookeeper 中维护着一个 ledger 到分区的映射。因而，当我们向集群添加一个新的存储节点时，我们所要做的就是在该节点上启动一个新的 ledger。现有的数据可以保留在原来的位置，不需要集群做额外的工作。 - 多租户 - 多租户基础设备可以跨多个用户和组织共享，同时保证它们彼此隔离。一个租户的活动不应当影响其他租户的平安或 SLA。 从根本上说，多租户可以从两个方面降低成本。首先，简约地共享单个租户没有充分利用的基础设备——将组件的成本分摊到全部用户。其次，通过简化管理——当有几十、几百或几千个租户时，管理一个实例明显简约很多。即便在一个容器化的世界里，“在这样一个共享系统上给我安排一个帐户”也比“为我供应这个服务的一个新实例”简约实现得多。全球性的问题可能由于分散在很多实例中而被掩盖。 与跨地域复制一样，多租户很难移植到没有这项设计的系统上。Kafka 是单租户设计，但 Pulsar 从内核上就支持多租户。 Pulsar 允许我们通过一个接口管理跨多个区域的多个租户，该接口包括身份验证和授权、隔离策略（Pulsar 可以选择在集群中划分出专供单个租户使用的硬件）和存储配额。CapitalOne 在这里对 Pulsar 的多租户做了很好的概述。 DataStax 供应的新 Pulsar 把握台进一步简化了这项工作。 - 队列（也即流） - Kafka 供应了一个经典的发布/订阅（publish/subscribe）消息模型——发布者发送消息给 Kafka，后者在主题中按分区排序，并给每个订阅者（或”消费者“）发送一份副本。 Kafka 用日志中的偏移量记录消费者已经看到了哪条消息。这意味着消息不能乱序确认，同时也意味着不能跨多个消费者共享订阅。（在其消费者分组设计中，Kafka 允许将多个分区映射到一个消费者，但不能反过来。） 这对于发布/订阅用例（有时称为流）来说很好。对于流，重要的是要以与消息发布时相同的挨次消费消息。 Pulsar 支持发布/订阅模式，但也支持排队模式，在后一种情况下，处理挨次并不重要，我们只想在任意数量的消费者之间平衡一个主题的消息： 这（以及面对队列的特性，如“死信队列”和支持重新发送的否定确认）意味着 Pulsar 经常可以取代 AMQP 和 JMS 以及 Kafka 风格的发布/订阅，接受 Pulsar 的企业有机会进一步降低成本。 与 Kafka 相比，Pulsar 的架构使它在跨地域复制、扩展、多租户和队列等方面具有重要的优势。 :/blog/2021/01/four-reasons-why-apache-pulsar-essential-modern-data-stack - END - 往期回顾 ◆ 如何