这篇主要是组件的职责和功能
- 每个JobManager负责一个Job，在提交JobGraph时创建，在job完成后销毁
- JobManager同样可以通过savepoint创建
ResourceManager
根据不同的集群调度框架提供不同实现（YARN，Mesos）
主要任务
- 处理资源请求（申请新的TaskManager）：在请求到来的时候可以启动新的container或者直接分配给job
- 异常检测：如果JobManager或者TaskManager挂了，需要做相应处理，通知相关组件
- 缓存TaskManager，以便重用。在TaskManager（container）一段时间未使用时自动释放
根据不同实现方式可以选择让ResourceManager感知到 task slot。（增加一个map变量即可实现）
ResourceManager 是在多个Job运行期间一直存活的
RecourceManager如果挂了不能影响当前执行的job，运行的job可以继续使用已经分配的资源执行，但是在RM挂了期间不能申请新的资源。
-
RM的不应该依靠保存运行时状态来实现容错
RM可以通过询问JM，TM来重新获取信息。（RM自身重新获取container,JM,TM的重新注册）
特殊情况下可能仍然需要保存一些与cluster-manager相关的状态。
JM向RM注册自己，这样便可以获得TM的信息。如果JM被分配的资源所在的TM挂了，会收到相关信息。
如果slot足够的话2,3步骤省略
TaskManager
同时和RM，JM进行信息交互。同时需要心跳信息来检测异常
与RM的交互
- TM启动的时候会在RM注册自己。RM断开连接时会重连，并重新注册自己，上报自身的slot资源信息
- 每次心跳时，TM也会发送自己的slot资源的可用状态。而且TM和JM直接链接并发送资源信息，这样RM就会及时的感知到资源的变化。
- TM这边看到的资源使用状态是最正确的信息（自己的哪个slot被分配给了哪个JM）。通过这个信息RM可以得到资源的使用状态
- RM会告诉TM，TM的哪个slot被分配给了哪个JM。之后TM会把slot分配给JM。如果分配失败会告诉RM对应的slot实际是不可用的（注：RM那边的信息可能是错误的，所以才会发送这个信息给TM，TM这边的信息才是资源使用的真是情况，参考上一条）
- RM会向TM发送shutdown信息
与JM的交互
- TM会根据JM的要求来分配slot给JM，在JM的Job完成之前这个slot都是属于JM的，完成后JM会释放slot
- TM会保存自己的slot分配信息（分配给了哪个JM），JM失连则会触发TM自身的master挂了的恢复逻辑
- JM可以部署任务到JM被分配的slot中
- JM失连，TM会尝试分配给slot给JM（如果JM有HA，则新的JM还是负责这个Job）。如果一段时间之内都注册失败，则所有分配给这个JM的slot都变为可分配状态。当之前Job的JM恢复后，他需要重新从RM申请slot
JM的slot pool
JM有一个资源池记录TM提供的slot资源
JM的调度器从slot pool中获取slot来调度任务，这样即使RM挂了JM也可以不失去分配的资源
InstanceManager是当前slot pool的一个实现
SlotPool在无法满足[资源申请]的时候会尝试从RM中获取资源，如果RM挂了或者RM不能提供资源或者请求超时，则[资源申请]失败
SlotPool可以返还资源给RM，如果应用已经使用了最大资源后slotpool还有剩余
Dispatcher
Dispatcher 接受client的job提交，并在cluster manager上创建启动job
[图片上传失败...(image-fc02df-1552733550212)]这个设计是因为
- 有的cluster manager需要一个集中式（触发 job 启动）和（监控job）的模块
- 可以作为一个常驻实例来等待任务提交
容错
核心容错机制是任务重启，并从checkpoint中恢复状态
YARN
with dispatcher
容错方面：
RM和JM运行在AM进程中，异常检测和进程重启由YARN执行
JobGraph和库，会保存在AM的工作目录中，YARN会将他们保存在私有的HDFS目录中
