Distributed Runtime Environment

任务与操作链

分布式执行时，Flink连接操作子任务到任务中。每个任务都被单独的线程执行。将多个操作连接到一个任务中是非常有用的优化：它减少了线程与线程之间的传输和缓冲的开销，并且在降低延迟的同时增加了总体吞吐量。连接行为是可以配置的，详细请见连接文档。
下图中的示例数据流有5个子任务，因此有5个并行线程。

Job Managers, Task Managers, Clients

Flink运行时由两种类型的进程组成：

• JobManagers(也称作masters)协调分布式执行。它们调度任务，协调检查点，当遇到故障时协调恢复等等。
  至少会有一个JobManager。高可用的配置会有多个JobManager，其中一个作为leader，其它的作为备份。
• TaskManagers(也称作workers)执行数据流的任务(或者更具体的说子任务)，并缓冲和交换数据流。
  至少得有一个TaskManager。

JobManagers和TaskManagers可以以不同的方式启动：作为一个标准集群直接在机器上启动,在容器中，或者由类似YARN或Mesos的资源框架管理。TaskManagers连接到JobManagers上，上报它们是可用的，并且被分配了工作。

client不是运行时和程序执行的一部分，但是用来准备和发送一个数据流给JobManager。然后，client可以断开连接，或者保持连接以接收进度报告。client要么是作为触发执行的Java/Scala程序的一部分，要么是在命令行过程中./bin/flink run ...

任务槽和资源

每个worker(TaskManager)是一个JVM进程，并且可能以不同的线程执行一个或多个子任务。为了控制一个worker能够接受多少个任务，worker有了所谓的任务槽(至少一个)。
每个任务槽代表了TaskManager的一个固定子集的资源。例如，一个TaskManager有三个槽，会为每个槽分配1/3的它管理的内存。对资源进行分槽意味着一个子任务不会与其它job的子任务竞争管理的内存，而是确定数量的预分配的内存。注意CPU并没有隔离：当前槽只隔离任务管理的内存。
通过调整任务槽数，用户可以定义有多少个子任务相互隔离。每个TaskManager只有一个槽意味着每个任务运行在一个单独的JVM上(例如，在一个单独的容器中启动)。多个槽意味着多个子任务共享JVM。相同JVM中的任务共享TCP连接(通过多路复用)和心跳消息。它们也共享数据集和数据结构，这可以降低每个任务的负载。

默认情况下，Flink允许子任务共享槽，即便它们是不同任务的子任务，只要它们来自相同的job。这样的结果是可能一个槽就持有job的整个管道。允许这种槽共享有两个主要的益处：

• Flink集群精确的需要和job中使用的最高并行度一样的任务槽数。而不需要计算一个程序总共需要多少个任务(有不同的并行度)。
• 更容易获得更好的资源利用。没有槽共享，非密集型的source/map()子任务会分配与资源密集型的窗口子任务一样多的资源。有了槽共享，在我们的示例中将基本并行度从二增加到六，从而充分的利用资源，同时确保了任务管理器中的重子任务是公平分配的。
  
  API也包含资源分组机制，用于组织不必要的槽共享。
  作为一个经验法则，合适的任务槽数应该是CPU的核数。通过超线程，每个槽可以获得两个或者更多的硬件线程上下文。

State Backends

存储的key/value索引的精确的数据结构依赖于state backend。一中state backend存储数据到内存哈希map中，另一种state backend使用RocksDB作为key/value存储。除了定义保存状态的数据结构外，state backend也实现获取某个时刻key/value状态快照并且保存快照作为检查点一部分的逻辑。

保存点

使用Data Stream API编写的程序可以冲一个保存点回放执行。保存点允许更新你的程序和你的Flink集群而不会丢失状态。
保存点是人工触发的检查点，它保存了程序的快照并且写入到state backend中。保存点依赖于常规的检查点机制。在执行程序期间，周期性的快照worker上的节点并且生成检查点。对于恢复来说，只有最后一个完成的检查点是需要的，并且只要一个新的检查点完成旧的检查点可以安全的删除。
保存点类似于这些周期性的检查点，除了它是由用户触发的，且当新的检查点完成时不会自动过期。保存点可以通过命令行创建或者通过REST API取消job时创建。