这篇主要是组件的职责和功能

• 每个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步骤省略

design-runtime-simple.png

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

yarn-without-dispatcher.png

with dispatcher

yarn-with-dispatcher.png

容错方面：

RM和JM运行在AM进程中，异常检测和进程重启由YARN执行

JobGraph和库，会保存在AM的工作目录中，YARN会将他们保存在私有的HDFS目录中