Flink Run time解析
整体架构
以上是flink的整体架构，今天我们一起来学习一下Flink的Runtime这一层。
Runtime架构
这个是runtime的架构，基本上一目了然。
图中可以看到，
1.client向cluster Management（standalone、yarn、messos、K8S）提交app请求。同时，client也会完成作业的编译以及优化的过程，譬如哪些task可以连在一块，输出输入类型是否匹配等，它将用户编写的table、stream、patch等转换成可以提交的jobGraph。
2.cluster启动一个AM（application master），在这个AM中又有三个组件，分别是dispatcher,ResourceManager,JobManager。AM也会将一些元数据信息存储的外部系统中
dispatcher：用来接受用户提交的作业，然后负责将JobManager拉起来。
ResourceManager：负责资源管理的，不是yarn里面的RM,，这个是单独的一个，在AM里面。
JobManager：负责作业执行，将jobGraph转换为ExecutionGraph。在作业的生命周期里面，可能会有多个任务(yarn session模式)，所以可能会有多个jobmanager。
3.JobManger接受到jobGraph后，向AM里的RM，去申请资源。如果这个时候，是yarn session的模式，那么RM会直接去找TM(Task Manager)去申请slot。如果不是，那么就会去找cluster Management去申请资源，然后cluster Management就会去启动Task Manager，然后，RM就可以去向TM去拿slot了，因为RM是知道TM的slot的使用情况，所以它是去通知TM，这个slot，JM要用了，而不是去和TM申请slot。
4.当TM接受到slot申请的时候，它就会把待分配的slot告诉JM，然后JM收到后，就会像对应的TM去提交task。TM接收到task后，就在slot中启动这些task。当所有task都启动后，这些task之间就会互相通信。会通过flink的shuffle模块来交互数据。
这里就提到了flink的两种运行模式：per-Job、session
Per-Job：
- 独享Dispather与Resource Manager
- 按需要申请资源（即TaskManager）
- 适合执行时间较大的作业
Session：
- 共享Dispatcher和Resource Manager
- 功效资源（即TaskManager）
- 适合规模小，执行时间短的作业
资源管理与作业调度
slot管理
slot管理主要分为三块：
ResourceManager: 主要是Slot Manager模块
- slot Manager：负责维护TM上的slot和slot的状态，并且有资源申请的时候，负责管理和分配slot的资源
TaskManager：实际持有slot资源，当slot的task任务结束后（不管是正常结束或者是异常结束），TM都会将信息发送给RM，告诉RM这个slot已经被释放掉了。同时，TM也会定期向RM、JM发送心跳，在心跳中会带上slot的信息，防止信息丢失。
JobManager：slot资源的申请者，他会管理整个task的进度。当JM接受到TM发过来的offerslot的时候，它会把slot的信息缓存在slotpool中。slotpool，会将受到的slot会前面的request进行匹配，匹配上后，就会将task分配到对应的slot中去。
slot sharing
单个slot中部署多个task，同一个Vertex的多个task能共享，意思是，A1，A2不能共享一个task
作业DAG图结构
Job-Graph：
客户端提交的作业DAG图结构，是逻辑结构，不考虑并发
ExecutionGraph
JobManager实际维护的数据结构，是物理结构，考虑并发。
Flink作业调度策略
Eager调度：适用于流作业。一次性调度所有的Task。
Lazy_From_Source：适用于批作业，上游作业执行完成后，调度下游的作业，所以相对来说，slot会占用的少一点，如图中，只要两份，因为但一个task（图中的绿点）运行完成后，slot就空出来了，可以给下面的task用。
错误恢复
Flink的错误又可以分为：Task Failover和Master Failover
Task Failover：1.单个task执行失败或TM出错退出等 2.可以有多种不同的恢复策略
Master Failver：AM执行失败
Task Failover
Restart-all
重启所有Task，从上次的Checkpoint开始重新执行
Restart-individual
只能重启出错的Task，这个只能用于Task间无连接的情况，应用极为有限
Restart-Region
这里涉及到两个概念：Pipeline边和blocking边
Pipeline指的是上游一个分区的数据都被下游的一个分区应用，如下图的A1-》B1或者C1-》D1这种的。如果是流式作业，那么A和B会同时起来，那么这个时候数据直接走网络就可以了
Blocking指的是上游的一个分区的数据被下游的多个分区所应用，如下图的B1-》C1和B1-》C2。像这种就是一般在批计算中，B1先起来，然后将数据写入磁盘或者一块内存中，供后续的task使用。
这个时候，它的策略是重启Pipeline Region : Blocking数据落盘，可以直接读取，逻辑上仅需重启通过pipeline边关联的Task。
它一般包括两种错误类型：1.作业自身执行失败 2.作业读取上游数据失败。
下图是两者错误类型所重启的region：
第一种：D1失败：
第二种：C1失败
Master Failover
多个Master通过ZK进行选主，目前Master Failover要求全图重启。