对于 Apache Pulsar

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

GitHub 地址：http://github.com/apache/pulsar/

导语：本文是 StreamNative 解决方案工程师魏彬在 TGIP-CN 032 直播流动的文字整顿版本。在流动中，率领大家意识了 Pulsar 测试环境搭建、周边工具到组件等方面，帮忙大家疾速动手 Apache Pulsar。

明天为大家带来 Apache Pulsar 疾速上手的内容，本次次要是面对刚刚接触 Pulsar 的同学，介绍如何疾速的搭建 Pulsar 测试环境，相熟 Pulsar 周边工具、相干组件。心愿通过这次分享，大家后续能本人依照这次分享的演练，疾速地把 Pulsar 相干集群、周边工具跑起来，为下一步进阶做好筹备。

本文内容次要分为以下三局部：

• Apache Pulsar 简介
• 如何疾速上手 Apache Pulsar
• Pulsar 周边监控运维工具的应用

Apache Pulsar 简介

简略介绍一下 Apache Pulsar，它是新一代的云原生分布式音讯流平台，这外面有几个关键词。云原生的话，置信大家应该都听得十分多了，简略能够了解成是面向 K8S，非常适合在 K8S 这种容器编排的零碎外面运作。音讯流平台是指 Apache Pulsar 是交融了音讯队列以及流解决两种个性的数据平台。

Pulsar 的呈现工夫是最晚的，大家能够从上图看到，Pulsar 是在 2012 年设计的，诞生起因是在它之前的我的项目没有满足过后创造者的需要。

Apache Pulsar 的定位

次要分为 Streaming（流解决生产模式）和 Queuing（队列生产模式），具体如上图。

对音讯队列来讲，它们的差别是什么？讲到音讯队列，拿 RabbitMQ 举例，一条音讯进来之后，只会给一个消费者去生产，也就是说它只 deliver 一次，生产完就完结了，不会去存它。

绝对应的，如 Kafka 代表的 Streaming 零碎，它的音讯容许有多个消费者，也就是说音讯进来一次，但能够被生产屡次。另外它的音讯是能够长久化到 Streaming 的平台，也意味着后续是能够做历史性数据的反复生产。

此外，在音讯队列场景中，对于音讯的生产没有严格的程序限度，一个音讯进来不会有严格的生产程序，不是必须先生产这个音讯。然而在 Streaming 平台，往往咱们会遇到严格的程序，必须依照音讯进来的程序去生产。

音讯队列与流不同的利用场景

音讯队列更多被使用到异步解耦的场景。简略举个例子，比方咱们做电商平台，用户下了一个单，之后你想给他发邮件或短信揭示一下。个别状况下，这种工作不太可能被放到主解决流程里。因为发邮件、短信绝对都是比较慢的解决逻辑，如果把它放到下单流程里，会导致下单服务的存储量很难下来。

这个时候咱们往往引入音讯队列，让音讯队列去把下单的服务和发邮件、发短信的服务解耦掉。然而流解决的场景更多是大数据的实时计算场景。音讯队列和流解决利用场景不一样导致催生了不同的产品。

Pulsar 的呈现让咱们能够在一个产品外面同时把音讯队列和流平台对立在一起，用户没有必要再去定位得那么细。在现有技术的场景外面，音讯队列和流解决的边界其实没有那么清晰。在用 Kafka 时，很多用户把它当一个音讯队列。如果严格依照方才的定义，很多用户其实是把 Kafka 当成一个异步解耦的平台在用。

音讯队列和流解决两者的外围的差别其实就是生产模型，也就是生产一次还是屡次生产、是否有程序。

Pulsar 在生产模型上可能反对队列、流的生产模型，所以它能够对立这两个场景，这也就是后面最早讲的“对立的云原生的音讯流平台”的一个解释。

如上图所示，展现了 Pulsar 反对的生产语义。通过后面对于流的定义，Exclusive、Failover 生产语义能够了解为 Streaming 流解决的生产模式，是严格依照音讯的程序生产的。

Shared 和 Key_Shared 模式容许乱序的生产，能够加很多的消费者从同一个 topic 外面读取数据。这个时候它是无序的，相似于咱们下面提到的 Queuing 生产队列的生产模式。

当 Pulsar 把这两种场景对立后，实际上在用的时候没有必要特地严格地再去想这到底是一个音讯队列的场景还是流场景，能够间接依照生产的需要去利用不同的生产语义。

Pulsar 为什么要对立这两种平台？它能够升高用户应用时候的心智老本，用户不须要再去在那么多的产品我的项目外面去筛选，在一个产品我的项目外面都能够解决。

Apache Pulsar 诞生要解决的问题

• 企业需要和数据规模

  • 多租户 – 百万 Topic – 低延时 – 长久化 – 跨地区复制

• 解除存储计算耦合

  • 运维痛点：替换机器、服务扩容、数据 rebalance

• 缩小文件系统依赖

  • 性能难保障: 长久化 (fsync)、一致性 (ack: all)、多 Topic
  • IO 不隔离：消费者读 Backlog 的时候会影响其余生产者和消费者

Apache Pulsar 架构

Pulsar 是存储和计算拆散的，最上层是 Producer、Consumer 用于生产音讯、生产音讯。上面一层是 Broker 计算层，再上面这层是 Bookie，能够看到有很多 Segment，这就是存储层，它以 Segment 为颗粒度提供一个存储层的服务。每一层节点都是对等的，相互支持独立扩大，十分便捷和灵便地反对咱们做扩容或者容错解决。

Apache Pulsar 个性

上图展现了很多 Pulsar 的个性，其中包含一些企业级的个性，大家感兴趣能够返回官网理解一下，如：

• 多租户
• 跨天文区域复制
• 高可用
• 提供的对立生产模型
• ……

这里不再赘述。

Apache Pulsar 外围组件

上图展现了 Pulsar 的三个外围组件：

• Broker（计算层）
• BookKeeper / Bookie（存储层）
• ZooKeeper（协调组件）

Broker

Broker 次要用于 Producer 和 Consumer 交互时的协定解析。Pulsar 有本人的一套交互协定，当 Producer 和 Consumer 与 Pulsar 交互须要基于 Pulsar 的协定去解决。

Kafka 在对外裸露服务的时候，也把本人的一套协定裸露了。当 Kafka 的 Producer 和 Consumer 生产的时候，用户要遵循 Kafka 的生产、生产协定，能力与 Kafka 去做交互。

Pulsar 的计算与存储层拆散意味着只有在计算层去兼容 Kafka 协定，就容许 Kafka 的 Producer 和 Consumer 把数据写到 Pulsar，咱们在计算层能够做不同的协定兼容。

除了 Kafka，咱们也能够做 AMQP、MQTT、RocketMQ 等协定兼容。因为计算层就是做协定的解析解决，自身这一层不会存任何数据，所有的数据在做了解析解决之后会被存到上游的 BookKeeper（存储层）里，当消费者来生产的时候，就从它外面读出来。

BookKeeper

接下来咱们看 Storage Layer，大家能够把它了解成是一个面向分片的设计。BookKeeper 提供的是一个面向 Segment 的存储语义，与它绝对比的就是 Partition（分区）的语义。分区的语义最常见的是像 Kafka 的这种语义。

Partition

Partition 跟 Segment 最大的区别在于 Partition 的量级往往是比拟大的。Kafka 的分区一旦与一个存储节点、存储设备、磁盘绑定，该 Partition 就只能在这个磁盘随着数据的写入越来越大，与这个存储磁盘绑定在一起。当咱们去做扩容或者迁徙的时候，Partition 越大，操作的老本就会越高。

Segment

Segment 的益处是什么？咱们能够去定义的它的大小下限。BookKeeper 或者在 Pulsar 的存储层其实也有 Partition 的概念，然而 Partition 曾经被打散成 Segment，不同的 Segment 又与底层的存储设备绑定。因为 Segment 是有大小的限定，老本就会十分小。这就是存储层以 Segment 语义去提供读写的服务带来的最大益处。

ZooKeeper

ZooKeeper 的职能：

• 提供元数据的治理
• 做 Service discover（服务发现）

Apache Pulsar 组件的网络流向

上图简略形容了一个流向，让大家能够了解组件之间的交互。Broker 与 BookKeeper 都会与 Zookeeper 产生申请交互。Broker 与 BookKeeper 的关系是：Broker 会把 Producer 或 Consumer 发来读写申请写到 BookKeeper 或者从 BookKeeper 读进来，Broker 相当于 BookKeeper 的 Client。

Apache Pulsar 组件的端口

再来看一下 Pulsar 组件对外的端口，启动服务的时候，咱们要对它的端口有清晰的理解。在上图中，Broker 裸露了一个 TCP 端口：6650，还有 HTTP 的端口：8080。6650 端口次要给 Client 去连贯，当 Produce 或者 Consume 时，它都会去连到 6650
的 TCP 端口；8080 端口裸露了一些监控指标，也就是兼容 Prometheus 协定的指标。另外一个就是它也裸露了 admin 的 API，当你要对 Pulsar 做运维的配置管理或者去取指标数据的时候，能够通过这个端口去获取。

BookKeeper 裸露的是 3181 TCP 端口，这个端口次要就是给 Broker 用，它通过连 3181 端口去连贯 BookKeeper。它也同时有 8080 HTTP 端口，次要裸露 Prometheus 的监控指标，是 Bookie 的一些监控指标。

ZooKeeper 的 2181 是很常见的 ZooKeeper 的 TCP 对外服务端口，这个端口是给 Broker、BookKeeper 去连贯的。Pulsar 的 ZooKeeper 外面也做了 8080 的 HTTP 端口，它次要是把 ZooKeeper 的一些指标给裸露进去。这些端口都是能够在配置外面本人去定义的，这里提到的都是默认端口号。

当然 Pulsar 所有的组件都是反对分布式的：在生产上，Broker 个别倡议至多两个，这样能够在其中一个挂了状况下，将流量切到另一个；bookie 倡议至多三个，在其中一个挂掉的状况下，数据在另外两个节点上还会存有备份；ZooKeeper 个别三个，足够应用。每一个组件都能够分布式，也就意味着每一个组件都能够依照本人的需要扩容 / 缩容，存储层不够能够加 BookKeeper 的节点，计算层不够能够加 Broker 上 Bookie 的节点，ZooKeeper 压力大能够治理 ZooKeeper。

上手 Apache Pulsar

心愿前文的介绍让大家对 Pulsar 有了概念，接下来咱们讲上手 Pulsar。Pulsar 有两个下载地址，官网地址与我的项目镜像地址（国内镜像源）。在官网地址中提供所有和 Pulsar 相干的组件，binary 即主 Pulsar；在上手阶段，大家能够跳过网站上周边生态组件；集成 SDK 能够在 Client 中查问；Pulsar Manager 是咱们后续会用到的 UI Dashboard 工具。国内用户从镜像源下载会更疾速。

Standalone 模式

首先咱们须要一个 Java 的环境，在本机装在 Oracle JDK/ Open JDK 1.8 版本。Standalone 是 Pulsar 提供的本机开发模式，上手阶段和本地起开发的时候举荐应用这个模式。Standalone 很简略，下载后只须要跑命令。此处列了两个命令，bin/pulsar standalone 在前台运行，bin/pulsar-daemon standalone 在后盾运行。详情能够参考 Standalone 文档，在视频 28:40 ～ 32:54 可参考使用 Pulsar 2.7.1 Standalone 的 demo。

常用命令举例

管理员命令：

• bin/pulsar-admin clusters list // 展现 Pulsar 集群
• bin/pulsar-admin broker list test // 查看集群 Broker
• bin/pulsar-admin topics list public/default // 查看 topic

Pulsar Client 命令：

• bin/pulsar-client produce my topic --messages“hello-pulsar” // 生产音讯
• bin/pulsar-client consume my topic -s“first-subscription” // 生产音讯

进一步理解 Pulsar 提供的命令行的、工具，能够查阅官网 client 文档和 Pulsar admin 文档。

集群模式

除了 Standalone 模式，很多人心愿在本地测试时能够应用和生产环境相似的集群模式，即领有多个 Broker 和 Bookie。一种可行的形式是在本地复制多个数据目录和配置文件去执行，能够参考 deploy-bare-metal 文档。另一种形式是，如果想在测试环境中如果想用集群模式，举荐应用 Docker 运行，参考 Github 仓库 Docker Compose 文档。

监控运维工具

有了能够运行的 Pulsar 后，接下来分享周边运维工具，比方如何去高效地治理集群、运维集群并观测集群；集群的生产生产数；topic 数据量等。

运维工具 Pulsar Manager

Pulsar Manager 用来治理 Pulsar 集群，其实现架构比较简单。后端用于连贯 Pulsar Broker 和 Bookie，本地也有长久化存储。

Pulsar Manager 架构图

倡议大家关上两个配置：一个是在 application.properties 配置文件内关上 bookie.enable=true 和 pulsar.peek.massage=true，另一个是在 bkvm.conf 配置文件内关上 bookie.enable=true。

监控工具 Prometheus & Grafana

Pulsar 的监控工具用的是云原生场景下最常见的 Prometheus 和 Grafana。因为 Pulsar 在设计之初就思考到了云原生，所以 Broker、Bookie、Zookeeper 都间接裸露了 8080 端口，拜访端口就会间接吐出 Prometheus 兼容的 metrics，只须要在 Prometheus 内加上 Broker、Bookie、Zookeeper。

StreamNative 建设了仓库，外面内置大量可用的 Dashboard。

应用 Prometheus

首先须要配置监控工具抓到相干指标。本地环境只须要通过 8080 端口配置，而在生产环境中 broker 等扩散在本人的端口内，多个 Broker、Bookie 都要独立配置。

接下来导入指标。在下面提到的 apache-pulsar-grafana-dashboard 仓库中有 Prometheus 文件夹，外面为大家提供了一些模版，大家能够参照模版去配置。

接入 Grafana

• 第一步创立数据源 Data Source 连贯 Prometheus。此处留神，如果是在本地本人执行，须要输出命令 .scripts/general-dashboards.sh <prometheus-url> <clustername>。
• 而后关上 Grafana Manage 开始导入，导入后上传 JSON 文件。

最初，也介绍了 Perf 压力测试，这里不再赘述，大家可查看上面回顾视频查看相干演示 Demo。

视频播放地址：https://www.bilibili.com/vide…

Apache Pulsar 入门材料

• TGIP-CN
• B 站
• [Apache Pulsar 干货集锦]()
• 官网文档
• 样例 1
• 样例 2

嘉宾介绍

魏彬 (@rockybean) Solution Engineer@StreamNative，Elastic Certified Engineer & Analyst，阿里云 MVP。

相干浏览

• 博文举荐|多图科普 Apache Pulsar
• 博文举荐|Pulsar 的音讯存储机制和 Bookie 的 GC 机制原理