YARN学习笔记 ResourceManager部分

CompositeService 多个service封装，service定义了状态机状态改变的合法状况。

重要的方法是（子类须要实现的）：serviceStart,serviceInit,serviceStop

 

里面的服务有:

Dispatcher,ClientRMService,ApplicationMasterService,AplicationMasterLauncher,AdminService,ContainerAllocationExpire,NMLivenessMonitor,NodeListManager

 

Context每一个服务对应有context。

子类定义serviceInit,ServiceStart,ServiceStop

继承的init,start,stop直接调用。

 

AbstractLivelinessMonitor父类，定义了monitor的一些基本操做。

这些服务的特色都是围绕dispatcher。

 

 

RMDispatcher有个register方法进行注册，将相应的Event以及对应的handler进行注册。

不出所料，里面不少服务都有queue，大多数都是异步完成。

Token之类的没有使用，暂时不用考虑。 

 

 

Event                                                  Type                                                  Handler

RMAppEvent                         RMAppEventType                          ApplicationEventDispatcher

RMStateStoreAppEvent  同上，是子类        

RMAppAttemptEvent             RMAppAttemptEventType             ApplicationAttemptEventDispatcher

                                               SchdulerEventType                       SchedulerEventDispatcher

RMNodeStatusEvent

 

状态机

StateMachineFactory<OPERAND, STATE extends Enum<STATE>, EVENTTYPE extends Enum<EVENTTYPE>, EVENT>

经过状态机把全部的状态转变都创建好后，在状态改变后自动执行。

 

 

 

一、Dispatcher里面有个queue，将全部的请求。

     每一个注册到Dispatcher的类最后都可以得到一个dispatcher的handler，用于将Event传入到Dispatcher的queue中，有可能有一个，也可能有多个handler，根据注册状况。

     Dispatcher内部有个线程用于将queue中得Event根据注册的handler,dispatch到不一样的类去处理。有些是同步有些是异步。

 

二、ResourceScheduler

 

 

三、ClientRMService

(1)实现的是ApllicationClientProtocol，完成的是client向Server(ResourceManager）的信息传输。

 

client submit一个job之后，提交到ClientRMService中，首先将该job,向RMAppManager submit这个job。

 

通过token，ACL验证。

而后交给Dispatcher进行处理，Event是RMAppEvent,Type的enum是RMAppEventType。

这个时候返回给Client端。

(2)生成一个RMApp类，表明一个application。向Dispatcher发送一个请求

RMAppEvent(applicationId, isRecovered ? RMAppEventType.RECOVER:

            RMAppEventType. START ));

 

这里面的EventType为RMAppEventType.START。RMAppEvent对应的Handler为ApplicationEventDispatcher。

RMStateStore指的是是否存储状态。

在RMAppImpl中，状态转变经过EventType肯定。

(3)随后进入RMStateStore中，生成一个ApplicationState状态，内部处理，内部进行handle,储存相应的state信息，若是不是能够recovery的话就是只打log。

随后出发RMAppEvent type的event,该Event的type是RMAppEventType.APP_SAVED

(4)随后代码流程从新进入RMAppImpl中，根据type，状态机流转到从State  NEW_SAVING到SUBMITTED,执行StartAPpAttemptTransition()

createNewAttempt(true);

(5)随后生成RMAppAttempt对象，根据id等等，把须要的参数加入。

随后进入RMAppAttemptImpl类的状态机，实现类是RMAppAttemptImpl

根据其状态机转变从RMAppAttemptState.NEW到RMAppAttemptState.SUBMITTED

transition类是AttemptStartedTransition类。

首先获取时间戳

进入ApplicationMasterService,该Service目的是沟通ApplicationMaster和ResourceManager。

  registerAppAttempt注册该ApplicationAttempt。

而后进入scheduler阶段

(6)在Scheduler阶段，首先是APP_ADDED

先无论内部逻辑，随后又进入到RMAppAttemptImpl中得状态转变

(7)EventType是RMAppAttemptEventType.APP_ACCEPTED,执行的transition类为ScheduleTransition类

它的行为是将首先将RMAppimpl的状态从submit调整到APP_ACCEPTED，没有行为。

随后在scheduler中分配资源，返回一个allocate对象。

 

至此client结束任务，下一步的任务不须要client参与了。

 

 

当NodeManager向ResourceManager汇报心跳的时候，RM会找到须要分配的资源，经过scheduler的方法去分配。在AppSchedulable方法中的assighContainer将该container assign到node中。同时通知该node须要去launch得app。这步是rm 和 nm进行通讯完成的，至关于rm向nm申请ApplicationMaster的Container。

 

 

 

 

NodeManager与ResourceManager通讯

协议是ResourceTracker，实现类是ResourceTrackerService