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>
通过状态机把所有的状态转变都建立好后,在状态改变后自动执行。
 
 
 
1、Dispatcher里面有个queue,将所有的请求。
     每个注册到Dispatcher的类最后都能够获得一个dispatcher的handler,用于将Event传入到Dispatcher的queue中,有可能有一个,也可能有多个handler,根据注册情况。
     Dispatcher内部有个线程用于将queue中得Event根据注册的handler,dispatch到不同的类去处理。有些是同步有些是异步。
 
2、ResourceScheduler
 
 
3、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 
上一篇:day24:面向对象设计与面向对象编程、类和对象


下一篇:#用Python直接写UTF-8文本文件