分布式运行环境
1、Tasks and Operator Chains
对于分布式执行过程，Flink将算子子任务链接到同一任务中。 每个任务由一个线程执行。 将算子链接到同一任务是一项有用的优化：它可以减少线程到线程切换和缓冲的开销，并在降低延迟的同时提高整体吞吐量。
2、Job Managers, Task Managers, Clients
Flink 运行环境包含两种过程
JobManagers(也叫master)协调分布式执行。 他们安排任务，协调检查点，协调故障恢复等。
一般至少有一个JobManager，在一个高可用的系统里，可能有多个JobManagers，其中一个是 leader，其它的是standby。（这个和hadoop的master有所差异，hadoop里一般只有一个master）
TaskManagers(也叫worker)，负责数据流task的执行(更准确的说是subtask的执行)，并缓冲和交换数据流。
实际必须要求至少有一个JobManager
JobManager和TaskManager可以以很多种方式启动：直接作为一个单独的集群在一台机器上启动，或者在容器里，或者由像YARN和Mesos这样的资源框架管理，启动之后，TaskManagers会连接JobManagers并汇报自己在可用状态，然后等待被分配工作。
client 并不是 runtime 和程序执行的一部分，它用于准备和发送数据流给 JobManager，随后就与JobManager断开连接，或者保持连接以接受执行过程的反馈。client 可以以 java或者Scala程序的形式执行，也可以用命令行的形式（./bin/flink run ...）执行
Task Slots and Resources
每一个worker都是一个JVM进程，可能会在不同的线程里执行一个或者多个subtask，为了控制一个worker能接收多少个task，worker有所谓的任务槽(至少有一个)
一个任务槽代表一个 TaskManager 的固定的资源子集。例如一个TaskManager 有三个任务槽，会把自己管理的内存分为三份给每一个槽，对资源分槽意味着子任务不会同其它作业的子任务来竞争被管理的内存，而是有一定数量的保留管理内存。注意到，这里只是对内存进行了分割，没有对CPU进行分割。
通过调整任务槽的数量，用户可以定义如何分离这些子任务。每一个TaskManager都有一个槽意味着每一个任务组都运行在一个独立的JVM里（例如在容器里启动），有多个槽意味着多个子任务共享一个JVM，同一个JVM里的任务通过TCP连接共享心跳信息，它们同样也共享数据集和数据结构，从而减少了每一项任务的开销。
默认地，Flink 允许子任务分享槽即使它们是不同任务的子任务，只要它们是来自同一个作业。这样的结果就是一个槽可以容纳作业的整个管道，这种共享槽有两个优点：
- Flink 集群需要与作业中使用的最高并行度完全相同数量的任务槽。而不需要去计算整个程序中总共包含多少个任务。
- 更容易地更好利用资源，如果不共享插槽，非密集型source/map（）子任务将阻塞与资源密集型窗口子任务一样多的资源。使用共享槽，将示例中的基本并行度从2增加到6，可以充分利用槽资源，同时确保重子任务在 TaskManager 中公平分布。
根据经验，一个好的默认的任务槽数量一般等于CPU的核数量，使用超线程时，每个插槽将占用2个或更多硬件线程上下文。
4、State Backends
存储键/值索引的确切数据结构取决于所选的状态后端。一个状态后端将数据存储在内存散列图中，另一个状态后端使用rocksdb作为密钥/值存储。除了定义保存状态的数据结构之外，状态后端还实现了获取键/值状态的时间点快照并将该快照存储为检查点的一部分的逻辑。
Savepoints
写入在数据流API里的程序可以通过保存点来恢复执行，保存点允许不丢失任何状态的同时更新你的程序和Flink集群。
保存点是手动触发的检查点，它获取程序快照并写入状态后端，它们依赖有规律的检查点机制，程序在执行期间定期在工作者结点进行快照并生成检查点，在恢复的时候只需要最新的一个检查点即可，当有一个新的检查点生成，那么之前的检查点就都可以被忽视。
保存点类似于这些周期性的检查点，除了它们是由用户主动触发的而且不会因为有新的检查点生成自动失效，保存点可以通过命令行创建或者当通过REST API取消一个作业时。
