Question

任务和算子链

对于分布式执行，Flink 链 算子子任务一起放入 任务 。每个任务由一个线程执行。将算子链接到任务中是一项有用的优化：它可以 Reduce 线程到线程切换和缓冲的开销，并在降低延迟的同时提高整体吞吐量。可以配置链接行为; 有关详细信息，请参阅 链接文档 。

下图中的示例数据流由五个子任务执行，因此具有五个并行线程。

TaskManager，JobManager，客户端

Flink 运行时包含两种类型的进程：

• 该 JobManagers （也称为 Masters ）协调分布式执行。他们安排任务，协调检查点，协调故障恢复等。

  总是至少有一个 Job Manager。高可用性设置将具有多个 JobManagers，其中一个始终是 Leader ，其他人处于 待机状态 。

• 该 TaskManagers （也叫 工人 ）执行 任务 （或者更具体地说，子任务）的数据流，以及缓冲器和交换数据 流 。

  必须始终至少有一个 TaskManager。

JobManagers 和 TaskManagers 可以通过多种方式启动：作为 独立集群 直接在计算机上，在容器中，或由 YARN 或 Mesos 等资源框架管理。TaskManagers 连接到 JobManagers，宣布自己可用，并被分配工作。

该 客户端 是不运行时和程序执行的一部分，而是被用来准备和发送的数据流的 JobManager。之后，客户端可以断开连接或保持连接以接收进度报告。客户端既可以作为触发执行的 Java / Scala 程序的一部分运行，也可以在命令行进程中运行 ./bin/flink run ... 。

任务槽和资源

每个 worker（TaskManager）都是一个 JVM 进程 ，可以在不同的线程中执行一个或多个子任务。为了控制工人接受的任务数量，工人有所谓的 任务槽 （至少一个）。

每个 任务槽 代表 TaskManager 的固定资源子集。例如，具有三个插槽的 TaskManager 将其 1/3 的托管内存专用于每个插槽。切换资源意味着子任务不会与来自其他作业的子任务竞争托管内存，而是具有一定数量的保存托管内存。请注意，此处不会发生 CPU 隔离; 当前插槽只分离任务的托管内存。

通过调整任务槽的数量，用户可以定义子任务如何相互隔离。每个 TaskManager 有一个插槽意味着每个任务组在一个单独的 JVM 中运行（例如，可以在一个单独的容器中启动）。拥有多个插槽意味着更多子任务共享同一个 JVM。同一 JVM 中的任务共享 TCP 连接（通过多路复用）和心跳消息。它们还可以共享数据集和数据结构，从而 Reduce 每任务开销。

默认情况下，Flink 允许子任务共享插槽，即使它们是不同任务的子任务，只要它们来自同一个作业。结果是一个槽可以保存作业的整个管道。允许此 插槽共享 有两个主要好处：

• Flink 集群需要与作业中使用的最高并行度一样多的任务槽。无需计算程序总共包含多少任务（具有不同的并行性）。
• 更容易获得更好的资源利用率。如果没有插槽共享，非密集 源/ map（） 子任务将阻止与资源密集型 窗口 子任务一样多的资源。通过插槽共享，将示例中的基本并行性从 2 增加到 6 可以充分利用时隙资源，同时确保繁重的子任务在 TaskManagers 之间公平分配。

API 还包括可用于防止不期望的时隙共享的 资源组 机制。

根据经验，一个很好的默认任务槽数就是 CPU 核心数。使用超线程，每个插槽然后需要 2 个或更多硬件线程上下文。

状态后台

存储键/值索引的确切数据结构取决于所选的 状态后台 。一个状态后台将数据存储在内存中的哈希映射中，另一个状态后台使用 RocksDB 作为键/值存储。除了定义保存状态的数据结构之外，状态后台还实现逻辑以获取键/值状态的时间点 SNAPSHOT，并将该 SNAPSHOT 存储为检查点的一部分。

保存点

用 Data Stream API 编写的程序可以从 保存点 恢复执行。保存点允许更新程序和 Flink 群集，而不会丢失任何状态。

保存点 是 手动触发的检查点 ，它会获取程序的 SNAPSHOT 并将其写入状态后台。他们依靠常规的检查点机制。在执行期间，程序会定期在工作节点上创建 SNAPSHOT 并生成检查点。对于恢复，仅需要最后完成的检查点，并且一旦新的检查点完成，就可以安全地丢弃旧的检查点。

保存点与这些定期检查点类似，不同之处在于它们 由用户触发， 并且在较新的检查点完成时 不会自动过期 。可以 从命令行 或通过 REST API 取消作业时创建保存点。