原文链接:https://ci.apache.org/projects/flink/flink-docs-release-1.3/concepts/runtime.html#task-slots-and-resources
Tasks and Operator Chains(任务及操作链)
在分布式环境下，Flink将操作的子任务链在一起组成一个任务，每一个任务在一个线程中执行。将操作链在一起时一个不错的优化:它减少了线程间的切换和缓冲，提升了吞吐量同时减低了时延。这些链式行为是可配置的，详情请见:https://ci.apache.org/projects/flink/flink-docs-release-1.3/dev/datastream_api.html#task-chaining-and-resource-groups
下图中的示例以5个子任务来运行，因此有5个并发的线程
JobManagers, Task Managers, Clients
Flink的运行时环境由两个进程组成:
JobManager：JobManager有时也叫Master，主要是协调分布式运行。他们调度任务，协调checkpoint，协调失败任务的恢复等等
一个Flink集群中至少有一台JobManager节点。高可用性的集群中将会有多台JobManager节点，其中有一台的leader节点，其他的是备节点。
TaskManager:TaskManager有时也叫Workers，TaskManager主要是执行dataflow中的任务，缓存数据以及进行数据流的交换。
每一个集群中至少有一个TaskManager。
JobManager和TaskManager可以有多种启动方式:直接在物理机上以standalone集群的形式启动，在容器中启动以及通过资源管理框架YARN或者Mesos来启动。TaskManager与JobManager进行通信，发送心跳信息来告知JobManager自己还处于活跃状态，同时接受JobManager分配的任务。
Client并不是运行时环境或者程序运行时的一部分，而是用来准备数据流和将数据流发送到JobManager中。之后client可以断开连接，或者继续保持连接来接收处理报告。Client要么作为触发执行的Java/Scala程序的一部分，或者是在命令行进程./bin/flink run …中
TaskSlots and Resources
每一个worker(TaskManager)是一个JVM进程，并在不同的线程中运行着一个或者多个子任务。为了控制每个worker可接受的最大任务数，每个worker需要有个task slots(任务槽)(至少有一个槽)。
每一个task slot代表着TaskManager的一个固定的资源子集，例如一个TaskManager有三个slot的话，意味着该TaskManager将会分配1/3的资源到每一个slot中去。将资源纳入槽中意味着一个任务不会跟作业中的其他任务竞争托管内存，而是会保留一定的托管内存。
注意：现在的slot还没有进行CPU的隔离，当前仅仅进行了托管内存的隔离。
通过调整slot的数量，用户可以自定义多少个任务之间彼此隔离。一个TaskManager有一个slot意味着每一个任务运行在一个独立的JVM进程中。有多个slot意味着多个任务共享一个JVM进程，共享JVM进程的任务之间共享TCP连接和心跳信息，同时共享数据集和数据结构，从而节省了每个任务的开销。
默认情况下，Flink允许subtask(子任务)之间共享slot，即使不是来自同一个task(任务)，只要这些subtask(子任务)来自同一个作业。允许slot共享的有两个好处:
1、Flink集群需要与任务并发度一样的的task slot(任务槽)，不在需要再去计算一个程序中总共包含了多少了task(任务)。
2、使得获取更好的资源利用率变得更加容易，没有slot共享的话，非密集型的source/map子任务将会拆分成与密集型的window子任务一样多的资源。有了slot共享，就可以提高任务的并发数，从2个到6个，充分利用了槽的资源，也保证了子任务公平地分布在TaskManager集群中。
API中还包括了一个资源组机制，可以用来防止不需要的slot共享。资源组资料：https://ci.apache.org/projects/flink/flink-docs-release-1.3/dev/datastream_api.html#task-chaining-and-resource-groups
根据经验法则，最好的slot数量配置是跟CPU核数一致，对于超线程，每个slot可以分配两个或者更多的硬件线程上下文。
StateBackends
存储key/value键值索引的切确数据结构取决于所选的state后端。一个state后端是将数据保存在内存的哈希map中，另一个则是以key/value的形式保存在RocksDB中。除了定义保存State的数据结构，State后端还实现了一个逻辑来获取key/value state的时间点快照并作为checkpoint的一部分保存起来。
Savepoints
用DataStream API书写的程序可以从一个savepoint中恢复执行。Savepoint允许更新您的程序而不丢失Flink中的任何state信息。Savepoint是手动触发checkpoint，获取程序的快照并将快照写入到state后端。它们依靠定期的checkpoint机制，在执行过程中程序在work节点上产生周期性快照，并生成checkpoint。对于故障恢复，只需要最新生成的checkpoint，旧的checkpoint可以在新的checkpoint生成之后就丢弃掉了。
Savepoint类似于周期性的checkpoint，除了他们是由用户手动触发的，并且并不会在新的checkpoint生成之后而自动更新。Savepoint可以通过命令行生成或者在调用REST API取消一个作业时产生。
