目录
资源抽象
ResourceManager（资源管理器）
SlotManager
SlotSelectionStrategy（Slot选择策略）
SlotPool（Slot资源池）
Slot共享组
1.SlotSharingGroup
2.CoLocationGroup
资源抽象
Flink涉及的资源分为两级：集群资源和Flink自身资源。集群资源管理的是硬件资源，包括CPU、内存、GPU等，由资源管理框架(yarn、k8s、Mesos)来管理，Flink从资源管理框架申请和释放资源
Flink从资源管理框架申请资源容器(Yarn的Container或者K8S的Pod),1个容器中运行1个TaskManager进程。容器的资源对于Flink来说是比较粗粒度的，如单个容器可以使用1个CPU核心，8G内存，因为计算类型的不同，一个任务占用一个容器可能无法充分利用资源，所以单个容器会被多个Flink的任务共享
Flink对申请到的资源进行切分，每一份叫做Task Slot,如下图
在1.14以前版本中是粗粒度资源管理(1.14版本增加细粒度资源管理，在 Flink 中还只是 beta 版本,详细见FLIP-169、FLIP-156和FLIP-56)，1个TaskMnanager的资源被等量切分成n份(n来自flink-conf.yaml配置文件)，也就是说TaskManager上最多可以运行n个Task，上图中1个TaskManager包含3个TaskSlot。
总体上来说，Flink 的资源调度框架中主要有三个角色，分别是 JobMaster (以下简称 JM)，ResourceManager (以下简称 RM) 和 TaskManager。用户写好的任务首先会被编译成 JobGraph，注入资源后提交到 JM，JM 的作用就是管理 JobGraph 的资源申请以及执行部署。
JM 中的调度相关的组件是 Scheduler，它会根据 JobGraph 生成一系列 SlotRequest，然后将这些 SlotRequest 进行聚合，生成一个 ResourceRequirement 发送给 RM，RM 接到资源声明以后，首先会检查集群中现有的资源能否满足其需求，可以的话就会向 TM 发出请求，让他给对应的 JM 去 offer slot (这里 slot 的分配由 SlotManager 组件来完成)。如果现有资源不够，它会通过内部的 driver 向外部的 K8s 或者 Yarn 申请新的资源，最终 JM 接收足够多的 slot 之后就会开始部署算子，作业才能运行起来。
ResourceManager（资源管理器）
作用：
- 申请容器启动新的TM,或者为作业申请Slot
- 处理JobManager和TaskManager的异常退出
- 缓存TaskManager（即容器），等待一段时间之后再释放掉不用的容器，避免资源反复的申请释放
- JobManager和TaskManager的心跳感知
Flink中内置了3中ResourceManager Driver,分别对应不同的资源管理框架
SlotManager
SlotManager面向不同的对象，提供不同的功能
- 对TaskManager提供注册、取消注册、空闲退出等管理动作。
- 对Flink作业，接收Slot的请求和释放、资源汇报等。当资源不足的时候，SlotManager将资源请求暂存在等待队列中，SlotManager通知ResourceManager去申请更多的资源，启动新的TaskManager,TaskManager注册到SlotManager之后，SlotManager就有新的资源了，从等待队列中依次分配资源。
SlotSelectionStrategy（Slot选择策略）
Flink在决定Task运行在哪个TaskManager上时，会根据策略进行选择，选择Slot的时候有不同的选择策略，SlotSelecionStrategy就是策略定义的接口，其类体系如下图
选择策略总体上分为两大类
- 位置优先的选择策略 LocationPreferenceSlotSelectionStrategy
位置优先的策略分为两类
- 默认策略：DefaultLocationPreferenceSlotSelectionStrategy，该策略不考虑资源的均匀分配，会从满足条件的可用Sloy集合选择第1个，以此类推
- 均衡策略：EvenlySpreadOutLocationPreperenceSlotSelectionStrategy，该策略考虑资源的均衡分配，会从满足条件的可用Slot集合中选择剩余资源最多的Slot，尽量让各个TaskManager均衡的承担计算压力
2.已分配Slot优先的选择策略 PreviousAllocationSlotSelectionStrategy
如果当前没有空闲的已分配Slot，则仍然会使用位置有限的策略来分配和申请Slot
SlotPool（Slot资源池）
JobMaster的调度器首先从SlotPool中获取Slot来调度任务，SlotPool在没有足够的Slot资源执行作业的时候,首先会尝试从ResoucreManager中获取资源，如果ResourceManager当前不可用、ResouceManager拒绝资源请求或者请求超时，资源申请失败，则作业启动失败
JobMaster申请到资源之后，会在本地持有Slot，避免ResourceManager异常导致作业运行失败。对于批处理而言，持有资源JobMaster首先可以避免多次向ResourceManager申请资源，同时ResourceManager不可用也不会影响作业的继续执行，只有资源不足时才会导致作业执行失败。
当作业已经执行完毕或者作业完全启动且资源有剩余时，JobMaster会将剩余资源交还给ResourceManager
Slot共享组
共享Slot条件：同一个Job的不同task的subtask
Flink 有两种共享组
1.SlotSharingGroup
非强制性共享约束，Slot共享根据组内的JobVerties ID查找是否已有可以共享的Slot,只要确保相同JobVertex ID 不能出现在一个共享的Slot内即可。
在符合资源要求的Slot中，找到没有相同JobVertex ID的Slot，根据Slot选择策略选择一个Slot即可，如果没有符合条件的Slot，则申请新的Slot
2.CoLocationGroup
CoLocationGroup又叫作本地约束共享组，具有强制性的Slot共享限制，CoLocationGroup用在迭代运算中，即在IterativeStream的API中调用。迭代运算中的Task必须共享同一个TaskManager的Slot。CoLocationGroup可以看成是SlotSharingGroup的特例。
此处需要注意，JobGraph向ExecutionGraph的转换过程中，为每一个ExecutionVertex赋予了按照并行度编写的编号，相同编号的迭代计算ExecutionVertex会被放入本地共享约束组中，共享相同的CoLocationContraint对象，在调度的时候，根据编号就能找到本组其他Task的Slot信息。
CoLocation共享根据组内每个ExecutionVertex关联的CoLocationConstraint查找是否有相同CoLocationConstraint约束已分配Slot可用，在调度作业执行的时候，首先要找到本约束中其他Task部署的TaskManager，如果没有则申请一个新的Slot，如果有则共享该TaskManager上的Slot。
