1、任务与操作链
分布式执行时，Flink将操作子任务按照相应的连接顺序放入到任务中，每一个任务都在单独的线程中执行，将多个操作连接到一个任务中是非常有用的优化:它减少了线程与线程之间传输与缓冲的开销，并且在降低延迟的同时增加了吞吐量。连接行为是可以配置的，详细请见连接文档。
下图中示例数据流有5个子任务，因此有5个并行线程。
2、Job Managers, Task Managers, Clients
Flink运行时有两种类型的进程:
(1) JobManagers(也称作masters)协调分布式执行。它们调度任务，协调检查点，当遇到故障时协调恢复等待。
至少会有一个JobManager。一个高可用的配置会有多个JobManager，其中一个是leader，其他为备份。
(2)TaskManagers(也称作workers)执行数据流任务(或者更具体的说子任务),并缓存和交换数据流。
至少有一个TaskManager。
JobManagers和TaskManagers能够通过各种各样的方式来启动:作为一个标准集群直接在机器上启动,在容器中或者由类似YARN或者Mesos的资源框架管理。TaskManagers连接到JobManagers上，上报它们是可用的，可被分配工作的。
client不是运行时和程序执行的一部分，但用来准备和发送一个数据流到JobManager。然后client断开连接，或者保持连接接收进度报告。client要么作为触发执行的java/scala程序的一部分，要么在命令行过程中./bin/flink run ...
3、任务槽和资源
每个woker(TaskManager)都是一个jvm进程，并且可以在不同的线程中执行一个或多个子任务。为了控制一个woker接受多少个任务，woker有了所谓的任务槽(至少一个)。
每个任务槽(task slot)代表了TaskManager的一个固定子集的资源。例如，一个TaskManager有三个槽，会为每个槽分配1/3的它管理的内存。对资源进行分槽意味着一个子任务不会与其他job的子任务竞争管理的内存，而是确定数量的预分配的内存。注意CPU并没有隔离,这些槽只是隔离在任务的管理内存。
通过调整任务槽的数量，用户可以定义有多少个子任务相互隔离。每个TaskManager只有一个槽意味着每一个任务运行在单独的JVM上(例如，在一个单独的容器中启动)。有多个槽意味着更多的子任务共用相同的JVM。在相同JVM中的任务共用TCP连接(通过多路复用)和心跳消息。它们也共用数据集合数据结构，这可以降低每个任务的负载。
默认情况下，Flink允许子任务共用槽，即便它们是不同任务的子任务。只要它们来自相同的job，这样的结果是可能一个槽就持有job的整个管道。允许这种槽共享有两个主要的益处：
(1)Flink集群需要和job中使用的最高并行度一样的任务槽数。而不需要计算一个程序总共需要多少个任务(有不同的并行度)。
(2)更容易获得更好的资源利用。没有槽共享，非密集型的source/map()子任务会分配与资源密集型的窗口子任务一样多的资源。有了槽共享，在我们的示例中将基本并行度从二增加到六，从而充分的利用资源，同时确保了任务管理器中的重子任务是公平分配的。
API也包含资源分组机制，用来防止不需要的槽共享。
根据以往经验，一个好的任务槽数量应该等于CPU核数。使用超线程，每个槽将占用2个或多个硬件线程上下文。
4、State Backends
key/value索引中的数据结构的存储依赖于state backend。一个state backend将数据存储在内存的哈希map中，另外一个state backend使用RocksDB进行key/value存储。除了定义拥有状态的数据结构外，state backends也实现了获取某个时刻key/value状态快照并且保存快照作为检查点一部分的逻辑。
5、保存点
在Data Stream API中编写的程序可以作为一个保存点重新执行。保存点可以更新你的程序和你的Flink集群而不会丢失状态。
保存点是人工触发的检查点，它保存了一个程序的快照并且写到了state backend中。保存点依赖于一定规则的检查机制，在执行程序期间会定期的在worker节点上进行快照并且生成检查点。恢复的时候只有最后一个完成的检查点是需要的，新的检查点产生后老的检查点就可以被安全删除。
保存点类似于这些周期性的检查点，除了它是由用户触发的，且当新的检查点完成时不会自动过期。保存点可以通过命令行创建或者通过REST API取消job时创建。