一.调度
Flink通过Task Slots来定义执行资源。每个TaskManager有一到task slot，每个task slot可以运行一条由多个并行task组成的流水线。这样一条流水线由多个连续的task组成，比如并行度n的MapFunction和并行度为n的ReduceFunction。需要注意的是Flink经常并发执行连续task，不仅在流式作业中到处都是，在批量作业中也很常见。
一个由数据源、MapFunction和ReduceFunction组成的Flink作业，其中数据源和MapFunction的并行度为4，ReduceFunction 的并行度为3。流水线由一系列的Source - Map - Reduce组成，运行在2个TaskManager组成集群上，每个TaskManager包含3个slot
Flink 内部通过 SlotSharingGroup 和 CoLocationGroup 来定义哪些 task 可以共享一个 slot， 哪些 task 必须严格放到同一个 slot。
二.JobManager
作业执行期间，JobManager会持续跟踪各个task，决定何时调度下一个或一组task，处理已完成task或执行失败的情况。
JobManager会接收到一个JobGraph，用来描述多个算子顶点（JobVertex）组成的数据流图，以及中间结果数据(IntermediateDataSet)。每个算子都有自己的可配置属性，比如并行度和运行的代码。除此之外，JobGraph 还包含算子代码执行所必须的依赖库。
JobManager 会将JobGraph转换成ExecutionGraph。可以将ExecutionGraph理解为并行版本的JobGraph，对于每一个顶点JobVertex，它的每个并行子task都有一个ExecutionVertex。
一个并行度为 100 的算子会有 1 个 JobVertext 和 100 个 ExecutionVertex。ExecutionVertex 会跟踪子 task 的执行状态。
同一个 JobVertext 的所有 ExecutionVertex 都通过 ExecutionJobVertex 来持有，并跟踪整个算子的运行状态。ExecutionGraph 除了这些顶点，还包含中间数据结果和分片情况 IntermediateResult 和 IntermediateResultPartition。前者跟踪中间结果的状态，后者跟踪每个分片的状态。
每个 ExecutionGraph 都有一个与之相关的作业状态信息，用来描述当前的作业执行状态。
三.高可用
流式应用通常都会设计7*24小时运行，因此对于它很重要的一点是：即便内部进程发生故障时也不能终止运行。为了从故障中恢复，系统首先要重启故障进程，随后需要重启应用并恢复其状态。
TaskManager故障
根据以前的内容，为了执行应用的全部任务，Flink需要足够数量的处理槽。假设一个Flink设置包含4个TaskManager，每个TaskManager有2个处理槽，那么一个流式应用最多支持以并行度8来运行。如果一个TaskManager出现故障，则可涌出来槽数量就降6个。
这时候JobManager会向ResourceManager申请更多处理槽（例如应用运行在一个独立集群）。JobManager无法重启应用，应用重启策略将决定JobManager以何种方式重启（后续文章介绍重启策略，篇幅有限）。
JobManager故障
和TaskManager相比，JobManager发生故障会更为棘手，它用于控制流式应用执行以保存该过程的元数据（如已完成检查点的存储路径）。如果负责管理JobManager进程消失，流式应用将无法继续处理数据。这就导致JobManager成为Flink应用中的一个单点失效组件。
为了解决该问题，Flink提供高可用模式，支持在原JobManager消失的情况下将作业的管理职责及元数据迁移到另一个JobManager。
Flink中高可用模式基于能够提供分布式协调和共识服务Apache ZooKeeper完成。它在Flink中主要用于“领导”选举以及持久且高可用数据存储。
流程
- Zookeeper请求存储位置，以获取JobGraph、JAR文件应用最新检查点在远程存储状态句柄。
- 向ResourceManager申请处理槽来继续执行应用。
- 重启应用并最近一次检查点重置任务状态。
参考
https://ci.apache.org/projects/flink/flink-docs-release-1.11/zh/internals/job_scheduling.html
《Stream Processing with Apache Flink》
