1.YARN架构和设计YARN的整体架构模式是Master/Slave主从模式。一个全局资源管理器(RM，master，可以有多个ha)和多个节点管理器一起构成一个计算框架。节点(NM)是每台机器的框架代理，管理单个节点的资源和任务，比如负责容器，监控其资源使用情况(cpu、内存、磁盘、网络)等。既然YARN是用来为计算框架调度、分配和管理资源的，那么就有不可或缺的与应用管理相关的框架：ApplicationMaster (AM)实际上是一个特定框架的库，它的作用是管理整个系统中的所有应用(从任务提交到任务完成)，从ResourceManager协商资源，与NodeManager一起执行和监控任务。

从上面这张Hadoop官网的照片，我们可以清楚的看到，YARN主要由以下三个组件组成：ResourceManager、Node NodeManager、ApplicationMaster。

2.纵观YARN三个组件的全貌，YARN可以看到一个很大的云操作系统，它负责启动ApplicationMaster(相当于主线程)，然后ApplicationMaster负责数据分段、任务分配、启动和监控，而ApplicationMaster(相当于子线程)启动的每个任务只负责自己的计算任务。计算完所有任务后，ApplicationMaster认为应用程序运行完成，然后退出。

2.1.ResourceManager全局资源经理RM负责整个系统的资源分配和管理；它主要由调度器、资源调度器和应用管理器组成。

2 . 1 . 1 resources chedulereresource调度器只负责资源的细分调度，比如根据队列、容量等指标给每个请求的应用分配指定数量的资源。Hadoop提供了三种不同的资源调度器可供选择，用户可以在配置文件中选择。这三种调度器是FIFO调度器、公平调度器和容量调度器。详情请参考官网或我的其他博客。纱线配置文件yarn-sire.xml来指定调度程序。Apache Hadoop集群的默认调度器是CapacityScheduler，而CDH的默认调度器是FAIR Scheduler。

yarn . resource manager . scheduler . class org . Apache . Hadoop . yarn . server . resource manager . scheduler . capacity . capacity scheduler

2.1.2应用管理器应用管理器负责整个系统中所有应用的管理，包括管理所有启动的ApplicationMaster (AM)实例，如启动AM，与AM通信并监控所有AM实例的运行状态，当一个AM在故障次数范围内发生故障时重新启动AM(默认情况下，一个应用的AM可以启动两次)。区分应用程序管理器和应用程序主机。前者管理后者的实例。

2.2 NodeManger，节点资源管理器NM是单个节点的资源管理器，管理单个节点的资源分配和任务。所以如果hadoop集群在特殊情况下要把存储和计算分开，有些节点只能启动Datanode或者Nodemanger，这样就只能是存储节点或者计算节点，当然也可以通过参数限制存储和计算的使用。所以NM是纱线的实际计算节点。

与NM RM保持心跳机制，定期报告自身节点的资源使用情况和容器的运行状态。容器，全称Resouce Container，是对YARN中资源的抽象(主要包括CPU、内存、网络等。).应用程序向RM请求资源的个体是容器，它由节点管理器分配。YARN会为每个任务分配一个容器，一个任务可以使用的资源值就是容器中分配的资源(新的容量调度支持容器资源的动态扩展)。NM接受来自AM的容器分配，CGroups是一种轻量级的资源隔离机制，用于启动和停止YARN。CGroups是一个Linux内核函数。从YARN的角度来看，这允许限制容器的资源使用。如果没有CGroups，就很难限制容器CPU的使用。NM只负责AM管理的应用的部分工作，不管整个程序是否失败，只负责执行容器。编辑总结：RM中有一个ResourceTrackerService类的resourceTracker对象，用于跟踪和管理NodeManager节点已知的资源变化。同时，NodesListManager类的对象nodesListManager维护一个节点列表，记录哪些节点当前可用，哪些不可用。ResourceTrackerService和NodesListManager拥有来自所有NodeManager节点的心跳报告，以及通过心跳进行交互的信息，如节点的当前状态、资源使用情况等。所有这些信息最终都会被收集到ResourceScheduler中，通过调度器将资源分配给用户。

2.3应用主应用管理器客户端在用YARN启动一个应用之前，先启动一个AM(其实就是一个运行的容器，一个程序最早的容器实例)。

提交给YARN的每个任务都将启动一个独特的AM实例。如果AM失败，默认情况下可以再次启动。AM与RM通信以提交所需的资源，AM与RM调度程序通信并协商以获得资源容器。在获得容器之后，AM分配它自己的任务来执行。例如地图任务的执行。有多少分配的容器就有多少并行执行的映射。从AM RM获得的资源只有资源列表、主机、容器数量、资源大小等。这时候AM需要和NM通信，启动任务，启动容器。AM监视该任务的所有任务实例的运行状态，例如MapReduce任务，它监视所有MapTask和Reduce task的运行状态。如果AM监控到任务失败，它可以重新申请资源重启。包括主动杀死任务、停止任务等。总结：从上面可以看出，纱线三个成分的RM和NM只与资源分配有关，只有AM与应用有关。因此，如果你想在一个新的计算框架(如用户自定义)/应用中使用YARN进行资源调度和任务管理，你只需要重新实现两个组件，前者是提交任务的客户端Client，后者是应用Master。比如MapReduce计算引擎可以直接配置使用YARN进行调度，也就是YARN已经默认为他实现了客户端JobClient和任务管理器MapReduce应用主(简称MRAppMaster)。

3.3之间的交流。纱线成分。RPC/IPC开发人员经常会看到RPC通信异常、IPC通信异常、错误等。在他们的任务中？或者检查监控指标RPC请求延迟等？大家应该都不陌生，那么这些错误是什么意思呢？怎么解决？

3.1RPC通信与IPC通信RPC通信是指远程过程调用通信协议，主要用于使主机A的程序在两台远程服务器之间调用主机B的子程序。它是一种远程分布式网络调用通信协议，我们不必过多关注底层网络通信的细节(TCP、UDP等。).它是一个打包的通信协议，可以直接使用。真的很香。通信是指进程间通信(IPC)协议，它是分布式系统通信的基石。虽然Java自带了一套RPC通信组件(RMI，remote method Invocation)，但是Hadoop并没有使用这个框架，因为相比Java的RMI，后者更加轻量级、高性能、可控。Hadoop RPC框架也是C/S模式，分为四个模块，分别是序列化层、函数调用层、网络传输层和服务器端处理层。目前有很多开源的RPC框架，比如Apache的AVRO，Google的Protocol Buffer。YARN的RPC通信使用Google的协议缓冲区作为默认的序列化机制，以获得更好的兼容性，而不是Hadoop自己的Writtable。在YARN中，任何两个需要相互通信的组件之间只有一个RPC协议。然而，对于任何RPC协议，通信方的一端是客户端，另一端是服务器，客户端总是主动连接到服务器。因此，YARN实际上采用了一种基于拉的通信模型。比如NM和RM的远程通信是基于RPC的，由ResouceTracker实现，其中RM是服务器，NM是客户端。NM主要通过调用ResouceTracker中的两个RPC函数与RM进行交互。前者在NM启动时通过registerNodeManager函数向RM注册，然后通过nodeHeartBeat发送类似RM的周期性心跳来维持两者之间的交互。如下图所示，因为RPC分为四层：序列化层、函数调用层、网络传输层和服务器端处理层，所以所有不同组件之间通信的“协议”是不同的。

1.JobClient通过这个RPC协议提交job client和RM之间的应用状态查询，使用的协议是ApplicationClientProtocol。2.AM和RM之间的协议是ApplicationMasterProtocol，AM通过这个协议向RM注册，为各种任务申请资源，或者在使用后自行销毁。3.AM和NM之间的协议是容器管理协议3。AM需要NM通过这个RPC协议启动/停止容器，获取每个容器的状态信息等。4.NM和RM之间的协议是ResourceTracker。NM通过这个RPC协议向RM注册，并定期发送心跳信息来报告当前节点的资源使用和容器操作。5.5之间的通信协议。Admin和RM是ResourceManagerAdministration协议，超级用户通过该协议更新系统配置文件，如节点的在线和离线列表、用户队列权限等。总结：RM、NM、AM三个组件通过不同的RPC框架协议相互通信，从而保持整个纱线资源的调度和任务监控。