关于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式核算为一体，选用核算与存储别离架构规划，支撑多租户、耐久化存储、多机房跨区域数据仿制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。 

GitHub 地址：github.com/apache/puls…

原文转载于 StreamNative，原作者李鹏辉，地址：streamnative.io/en/blog/tec…

本系列上一篇文章《根据 Pulsar 业务完结的 Exactly-Once（准确一次）语义》介绍了在 Apache Pulsar 中，能够经过启用 Transaction API 确保准确一次语义。本文将具体介绍多种音讯传递语义，包括：

  • 经过幂等 producer 支撑单个 topic 准确一次语义
  • 业务 API
  • Pulsar 与 Flink 集成时端对端仅且只处理一次语义

本文将深化解析 Apache Pulsar 中的业务，帮助读者熟悉 Pulsar 业务 API 的首要概念，以便后续运用。

为什么需要业务？

业务增强了音讯传递语义和流处理过程中处理确保（例如：运用 Pulsar Functions 或与其他流处理引擎集成）。流处理一般表现为“消费-处理-出产”，在一个数据流中出产和消费（例如：Pulsar Topic）。

随着流处理的兴起，对具有更强处理确保的流处理运用的需求也在不断增加。例如，金融机构运用流处理引擎来处理用户的借贷业务。这种场景要求每条音讯都只处理一次且无反常。

图片

换句话说，假如流处理运用消费 A 音讯 并将生成的结果当作音讯 B(B = f(A)) ，那么准确一次处理确保意味着，只要在成功生成音讯 B 时，A 才会被符号为已消费，反之亦然。 

在 Pulsar 2.8.0 之前，运用 Apache Pulsar 构建流处理运用时，完结准确一次处理确保的操作都不简单。将 Pulsar 与流处理引擎（如 Flink）集成或许能够完结准确一次确保。例如，你能够运用 Flink 准确一次读取从 Pulsar topic 中的音讯，但不能准确一次将结果写入到 Pulsar topic。

当为 Pulsar producer 和 consumer 配置至少传递一次语义时，流处理运用无法在以下场景中完结准确一次处理语义：

  • 重复写入：由于内部重试逻辑，producer 或许会多次写入同一条音讯。幂等 producer 经过音讯去重来处理这个问题。
  • 运用程序溃散：流处理运用程序或许在任何时候溃散。假如运用程序在写入结果音讯 B 之后，但未将源音讯 A 设为已消费（即 ack）时溃散，运用程序在重启后会重新处理源音讯 A，导致音讯 B 重复写入到输出 topic，违背了准确一次处理的确保。
  • 僵尸运用程序：在分布式环境中，流处理运用或许会从网络中分区（如网络暂时不行用）。一般，同一流处理运用程序的多个新实例会主动启动，以替换“丢掉”的实例。在这种情况下，同一处理运用程序的多个实例或许在并行运转，这些实例会处理相同的输入 topic，并将结果写入相同的输出 topic，导致输出重复的音讯，违背准确一次处理语义。

Pulsar 在 2.8.0 版别中引入了新业务 API，旨在处理在上述场景 2、3 中不能完结准确一次处理语义的问题。

业务语义

业务 API 使流处理运用程序能够在一个原子操作中消费、处理和出产音讯。这意味着，在同一业务中的一批音讯能够从许多 topic 分区接纳、出产和承认。处理同一业务的一切操作为一个全体，要么悉数成功，要么悉数失败。

那么业务 API 怎么处理上述三个问题呢？

跨多 topic 的原子写入与承认

首要，业务 API 支撑将多个 Pulsar topic 作为单个全体进行原子写入和原子承认。在一个业务中出产或消费的一切音讯一起被成功写入或承认，或者没有音讯被成功写入或承认。例如，处理过程中的过错或许导致业务间断，在这种情况下，任何 consumer 都不会消费到该业务生成的任何音讯。这对“消费-处理 -出产”原子操作意味着什么？

假定运用程序消费来自 topic T0 的音讯 A，并在对音讯 A（B=f(A)）运用一些转化逻辑后生成结果音讯 B 到 topic T1，那么仅当音讯 A 和音讯 B 被以为成功地一起消费和发布，或者根本不被消费也不被发布（即什么都不做）时，此刻消费-处理-出产整个操作才是原子的。只要当音讯 A 被成功承认时，咱们才以为是在 topic T0 中消费了此音讯。

图片

业务 API 确保音讯 A 的承认和音讯 B 的写入以原子操作发生，此刻才以为“消费-处理-出产”整个操作为一个原子操作。

经过条件承认阻隔僵尸实例

咱们经过条件承认来处理僵尸实例的问题。条件承认指当两个业务企图承认同一音讯时，Pulsar 确保只要一个业务能够承认成功，另一个业务的承认会被间断。

读业务音讯

读取由业务写入的音讯会有怎样的确保？

只要在业务已提交时，Pulsar broker 才会向 consumer 分发业务音讯。换句话说，假如业务仍在进行中，则 broker 不会分发其中的音讯；也不会传递处于间断状况的业务音讯。

但是，Pulsar 并不确保在一个提交的业务中出产的音讯会同时被消费。有以下几个原因：但 Pulsar 不确保同时消费在同一个提交业务中出产的音讯，原因如下：

  1. 参加提交业务的 topic 分区数量很多，consumer 不必定能消费到一切分区上的音讯，因而无法读取该业务中生成的一切音讯。
  2. Consumer 的承受行列巨细或缓冲区巨细或许不同，因而只能接纳必定数量（或许是恣意值）的音讯。

业务 API

业务特性首要是服务器端协议级特性。目前业务 API 只支撑 Java 客户端（未来将会支撑更多言语的客户端）。用 Java 编写，运用 Pulsar 业务 API 的“消费-处理-出产”运用程序示例如下：

图片

让咱们按过程分析这个例子。

图片

业务的完结

本节扼要概述业务 API 引入的新组件和新恳求流程。你能够阅览相关文档，或回看 Pulsar 北美峰会上的相关视频了解更多关于业务的具体信息。

本节只介绍与业务相关的首要概念，为用户调试或调优业务，供给参考。

图片

组件

业务和谐器和业务日志

业务和谐器（Transaction Coordinator，TC）维护与业务交互的 topic 和订阅。提交业务时，业务和谐器与 topic owner broker 交互以完结业务。

业务和谐器（ TC ）是一个在 Pulsar broker 中运转的模块，全程维护业务，并阻挠业务进入过错状况。业务和谐器也处理业务超时，确保业务在超时后间断。

一切业务元数据都保存在业务日志中，而业务日志保存在 Pulsar topic 中。业务和谐器溃散后，仍能够从业务日志中康复业务的元数据。

每个业务和谐器都有业务日志 topic 的分区子集，也就是说，（业务和谐器地点的） broker 是（topic） 分区的 owner。

每个业务都有仅有的业务 id（TxnID），长度为 128 位。最高的 16 位用于表明业务日志地点的 topic 分区，其余位为根据 TC（此业务日志地点的 topic 分区的 owner） 生成的单调递加数值。

值得注意的是，业务日志 topic 只存储业务的状况，不存储业务中的音讯。音讯存储在 topic 分区中。业务能够处于多种状况，如“ Open ”、“ Prepare commit ”和“ committed ”。业务日志中存储业务的状况信息和相关的元数据。

业务缓冲区

业务中的音讯（原存储在 topic 分区中）存储在对应的 topic 分区地点的 broker 业务缓冲区中。在提交业务前，业务缓冲区中的音讯对 consumer 不行见。业务间断时，业务缓冲区中的音讯将被丢掉。

Pending ack 状况

在提交业务前，业务中的音讯承认处在 pending ack 状况。假如音讯处于pending ack 状况，则在业务间断时，音讯未从 pending ack 状况中移除，其他业务无法承认该音讯。（音讯不能被其他业务承认直到此音讯移除 pending ack 状况。）

pending ack 状况保存在 pending ack 日志中。pending ack 日志存储在游标日志中。重启后 broker 能够从 pending ack 日志还原业务状况，确保 ack 不会丢掉。

数据流

从上层 API 可看出，数据流能够分为多个过程：

  • 敞开业务；
  • 发布业务音讯；
  • 承认业务音讯；
  • 完结业务。

敞开业务

在业务开端时，Pulsar 客户端向定位业务和谐器恳求新的业务 ID。收到恳求后，业务和谐器为业务分配业务 ID。然后，主动生成该业务的日志，并记载其id和状况（ OPEN，如过程 1a 所示），确保业务状况耐久化（不必忧虑业务和谐器溃散）。记载业务状况后，TC 将业务 ID 回来给 Pulsar 客户端。

发布业务音讯

在 Pulsar 客户端向新的 topic 分区发送音讯之前，客户端恳求 TC 将此 topic 分区添加到业务中。TC 将分区的更改记载并耐久存储在其业务日志中（如 2.1a 所示），确保 TC 知道业务正在处理的一切分区。因而，在 end-partition 时，TC 能够提交或间断此 transaction 在一切分区上的改变。

Pulsar 客户端开端向分区发送音讯，此发送流程与正常的音讯发送流程完全相同。仅有的区别是业务生成的批音讯包括业务 id。接纳该批音讯的 broker 检查该批音讯是否归于某个业务。假如不归于某个业务，那么 broker 会正常处理写操作；否则，broker 将该批音讯写入分区的业务缓冲区。

带着业务 Ack 音讯

Pulsar 客户端第一次订阅被承以为业务的一部分时向 TC 发送恳求。在过程2.3a中，TC 记载对业务的新订阅，确保 TC 知道业务正在处理的一切订阅，因而 TC 能够在 EndTxn 阶段提交或间断对每个订阅的更改。

Pulsar 客户端开端 ack 订阅上的音讯，此业务承认流程与正常承认流程相同，但业务承认恳求中包括业务 id。接纳 ack 恳求的 broker 检查此 ack 是否归于某个业务，假如归于某个业务，则 broker 将音讯符号为：PENDING_ACK 状况，即在提交或间断该 ack 前，其他 consumer 不能 ack 或 nack 此音讯，然后确保当两个业务在 ack 同一条音讯时，只要一个业务能够 ack 成功，另一个则将被间断。

Pulsar 客户端测验承认音讯时，假如在单个承认和累积承认中都检测到冲突，则会间断整个业务。

完结业务

在业务完毕时，运用程序将决议提交或间断业务。假如在承认音讯时检测到冲突，也能够间断业务。

当业务完结时，Pulsar 客户端能够向 TC 恳求完毕业务，并用一个字段标识业务是提交还是间断。

TC 将提交或间断音讯写入其业务日志（如 3.1a 所示），并向该业务中触及的一切分区发送提交或间断业务恳求。如 3.2 所示。

当接纳到恳求的一切分区都成功提交或间断业务后，TC将提交或间断的音讯写入其业务日志。如图中 3.3 所示。

业务功能怎么

本文已经解说了业务的语义及作业原理，接下来咱们来看看业务的功能。

业务 producer 功能

业务仅导致中等程度的写放大。额定写入出现的首要原因如下：

  • 关于每个业务，producer 都会收到额定的恳求，以便向业务和谐器注册 topic 分区。
  • 当业务完结时，向参加该业务的一切分区写入业务符号。
  • TC 将业务状况改变写入业务日志。一切添加到业务的 topic 分区的状况（xxx）都会被/更新/记载（下来）。（“预备提交”和“已提交”状况）。

开销与作为业务部分写入的音讯数无关。因而，进步吞吐量的要害是每个业务包括很多的音讯。减少音讯数量或缩短业务提交时刻都会降低吞吐量。

增加业务持续时刻的后果是增加了端到端延迟。回想一下，consumer 并不会读取到未提交的业务音讯。因而，提交间隔越长，consumer 等候的时刻就越长（不得不等候），然后增加了端到端延迟。

业务 consumer 的功能

业务 consumer 比 producer 简单得多。一切的（业务）逻辑都由 Pulsar broker 服务器端完结，broker 仅分发已完结的业务音讯。

扩展阅览

本文扼要介绍了 Apache Pulsar 业务的相关信息。你能够阅览以下材料，深化了解 Pulsar 业务：

  • 规划文档：介绍公共接口、数据流和组件的官方文档，文档中还包括怎么完结业务组件、怎么处理业务恳求、怎么铲除业务数据等。
  • Pulsar 客户端 Javadocs[3] : 介绍怎么运用新 API。
  • 根据 Pulsar 业务完结 Exactly-Once 语义 ：本系列博客的第一篇。

我的同事郭斯杰和 Addison Higham在 6 月 16 日至 17 日举行的 Pulsar Summit 北美峰会 2021上分享了“ Exactly-Once 如此简单：Apache Pulsar 中的业务音讯”。观看讲演视频，了解 Pulsar 业务的更多细节。

定论

本系列的第一篇博客文章《凭借 Pulsar 业务机制，完结准确一次语义如此简单》介绍了 Apache Pulsar 的业务 API 怎么启用准确一次语义。在本文中，咱们讨论了 Apache Pulsar 中业务 API 的要害规划方针、业务 API 的语义，以及 API 实践怎么作业。

假如咱们把流处理看作一个读-写处理器，那么这篇博文将要点放在读和写途径上，而处理本身则是一个黑匣子。但是，在实践处理阶段会发生很多事情，导致仅运用业务 API 无法确保准确一次处理。例如，假如处理逻辑修改了外部存储系统，那么这儿介绍的业务 API 不足以确保准确一次处理。

Pulsar 和 Flink 集成经过业务 API 为各种流处理运用程序供给端到端的准确一次处理，乃至处理期间更新那些额定状况存储。

在接下来的几周里，咱们将分享本系列的第三篇文章，具体介绍 Pulsar 和 Flink 集成怎么根据新的 Pulsar 业务供给端到端的准确一次处理语义，以及怎么运用 Pulsar 和 Flink 轻松编写流运用程序。

相关阅览

  • 技术探究：Apache Pulsar 的业务型事件流
  • Pulsar 2.7.0 新增特性概览：业务支撑、Topic 等级策略配置等

译者简介

资飞，资深架构师，Apache Pulsar Contributor，目前在某初创公司担任数据平台、交易平台建设，个人在金融证券领域已有 9 年的作业经验，专注证券业务以及分布式核算方向，喜爱读书、烹饪、旅游，重视分布式、高并发、内存交易相关的技术。

点击链接 ，获取 Apache Pulsar 硬核干货材料！