Flink基础 之 分布式运行环境（Runtime Environment）

任务和算子链

对于分布式执行，Flink 将每个算子的子任务链接成一个任务。一个线程相当于一个任务。将算子链接成为一个任务减少了线程间的切换和缓冲的开销，增加了总体的吞吐量，降低了延迟。算子链可配置，详情请查阅：Flink流处理（Stream API）- Operators（操作数据流）

下图中的示例数据流使用5并行线程执行5个子任务。

JM、TM、客户端

Flink Runtime 由以下两部分组成：

• JobManagers 用来协调分布式执行。他们调度任务、协调 chenkpoint、协调故障恢复等等。

至少有一个工作经理。一个高可用性的设置将有多个作业管理器，其中一个总是领导者，其他的都是备用的。

• TaskManagers 执行数据流的任务(或者更具体地说，子任务)，并缓冲和交换数据流。

必须始终至少有一个TaskManager。

 

JM 和 TM 可以以多种方式启动：直接在机器上作为独立集群启动，或者在容器中启动，或者由 YARN 或 Mesos 之类的资源框架管理。TM 连接到 JM，通知 JM 自己可用，并由 JM 分配工作。

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

任务槽和资源

每个 worker  (TaskManager)都是一个 JVM 进程，可以在单独的线程中执行一个或多个子任务。为了控制 worker 接受多少任务，worker 具有 task slots 这么一个概念(至少一个)。

每个 task solt 表示 TaskManager 资源的一个固定子集。例如，一个有三个插槽的 TM 会将其1/3的托管内存分配给每个插槽。分配资源意味着子任务不会与来自其他作业的子任务争夺托管内存，而是拥有一定数量的预留托管内存。注意，这里没有发生CPU隔离；当前插槽只分隔任务的托管内存。

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

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

• Flink集群需要的任务插槽与作业中使用的最高并行度一样多。不需要计算一个程序总共包含多少任务(具有不同的并行度)。
• 更容易得到更好的资源利用。如果没有插槽共享，非密集型 source/map() 子任务将阻塞与资源密集型窗口子任务一样多的资源。使用插槽共享，将我们示例中的基本并行度从2提高到6，可以充分利用插槽资源，同时确保繁重的子任务在 TM 中得到公平分配。

这些 APIs 还包括一个资源组机制，可用于防止不需要的插槽共享。有关资源组，请查阅：Flink流处理（Stream API）- Operators（操作数据流）

最好是 task solt = CPU cores。

后端状态

存储 key/values 索引的数据结构取决于所选的状态后端。一个状态后端将数据存储在内存中的散列映射中，另一个状态后端使用 RocksDB 作为 key/value 存储。除了定义保存状态的数据结构外，状态后端还实现了获取 key/value 状态的时间点快照的逻辑，并将该快照存储为 checkpoint 的一部分。

Savepoints

在数据流 API 中编写的程序可以从 savepoint 恢复执行。savepoint 允许在不丢失任何状态的情况下更新程序和 Flink 集群。

savepoints 是手动触发的 checkpoints，它获取程序的快照并将其写入状态后端。它们依赖于常规的 checkpoints 机制。在执行过程中，程序定期在工作节点上快照并生成 savepoints。对于恢复，只需要最后一个完成的 checkpoint，而旧的 checkpoint 可以在新 checkpoint 完成时安全地丢弃。

Savepoints 类似于这些定期 checkpoints，但它们是由用户触发的，并且在更新的 checkpoints 完成时不会自动过期。可以从命令行创建 Savepoints，也可以在通过 REST API 取消作业时创建。