“The purpose of human life is to serve, and to show compassion and the will to help others.”
JobClient、JobTracker、TaskTracker
|  |
JobTracker 负责工作节点的资源管理，监控资源的使用情况，管理作业的生命周期。
TaskTracker 的职责是根据JobTracker 的命令启动/清除任务，并且周期性的向JobTracker 汇报任务的状态信息。
Yarn运行机制
YARN 的基本思想就是将JobTracker 的两大主要职能：资源管理、作业的调度监控分为两个独立的进程。一个是全局的ResourceManager,另一个是每一个应用对应的ApplicationMaster。
ResourceManager 是一个纯粹的调度器，它根据应用程序的资源请求严格限制系统的可用资源。在保证容量、公平性及服务器等级的前提下，优化集群资源利用率，即让所有的资源都能被充分利用。
ApplicationMaster 负责与ResourceManager 协商资源，并和NodeManager 进行协同工作来执行容器和监控容器的状态。
NodeManager 是YARN 节点上的工作进程，管理集群中独立的计算节点。其职责包括启动应用程序的容器，监控它们的资源使用情况，并且报告给ResourceManager。
|  |
一个全局 ResourceManager 以主要后台进程的形式运行，它通常在专用机器上运行，在各种竞争的应用程序之间仲裁可用的集群资源。 在用户提交一个应用程序时，一个称为 ApplicationMaster 的轻量型进程实例会启动来协调应用程序内的所有任务的执行。这包括监视任务，重新启动失败的任务，推测性地运行缓慢的任务，以及计算应用程序计数器值的总和。有趣的是，ApplicationMaster 可在容器内运行任何类型的任务。 NodeManager 是 TaskTracker 的一种更加普通和高效的版本。没有固定数量的 map 和 reduce slots，NodeManager 拥有许多动态创建的资源容器。
在介绍这个问题之前，先来总结一下java中的内存是如何管理的：
有向图的方式进行内存管理，精度高，但是效率较低，可以处理引用循环等问题。例如有三个对象互相引用，只要和根进程是不可到达的，就可以被GC回收。如果具有满足以下两个条件的对象：
那么这些对象是无用的，但是占用着内存空间，并且不会被GC回收这就是所谓的内存泄漏。
说直白点，就是程序在申请内存后，无法释放已经申请的内存空间。你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序，这就是内存泄漏。一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。
内存泄漏一般可以分为以下四种类型：
常发性内存泄漏：发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。偶发性内存泄漏: 发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生.常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。一次性内存泄漏： 发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。隐式内存泄漏： 程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。与C++的比较
在C++中，内存泄漏的范围更大，因为C++不存在垃圾回收机制，因此对于那些不可达的对象，C++是永远都无法回收的。但是Java中不可达的对象是由GC负责的，因此程序员不用考虑这一部分对象，这在一定程度上减轻了开发难度。
在Java中，对程序员来说，GC基本是透明的，虽然我们可以调用System.gc();通知垃圾回收机制进行回收，但是该函数不保证JVM一定会执行GC。因为不同的JVM实现者可能使用不同的算法管理GC。
通常，GC的线程的优先级别较低。JVM调用GC的策略也有很多种，有的是内存使用到达一定程度时，GC才开始工作，也有定时执行的，有的是平缓执行GC，有的是中断式执行GC。但通常来说，我们不需要关心这些。除非在一些特定的场合，GC的执行影响应用程序的性能，例如对于基于Web的实时系统，如网络游戏等，用户不希望GC突然中断应用程序执行而进行垃圾回收，那么我们需要调整GC的参数，让GC能够通过平缓的方式释放内存。
内存泄漏实例
1
2
3
4
5
6
7
Vector v=new Vector(10);
for (int i=1;i<100; i++)
{
Object o=new Object();
v.add(o);
o=null;
}
在这个例子中，我们循环申请对象o，并将o放入容器中，虽然我们释放了o，但是由于容器还引用这这个对象，所以GC仍然是不会回收的。我们需要通过释放容器才能被GC回收。
如果内存泄漏非常严重的话，最终会导致内存溢出。下面给出常见的几种内存溢出的分类：
1. OutOfMemoryError： PermGen space
PermGen Space指的是内存的永久保存区,该块内存主要是被JVM用来存放class和mete信息的，当class被加载loader的时候就会被存储到该内存区中，与存放类的实例的heap区不同，java中的垃圾回收器GC不会在主程序运行期对PermGen space进行清理。因此，程序启动时如果需要加载的信息太多，超出这个空间的大小，则会发生溢出。
解决方案：增加空间分配——增加虚拟机中的XX:PermSize和XX:MaxPermSize参数的大小，其中XX:PermSize是初始永久保存区域大小，XX:MaxPermSize是最大永久保存区域大小。
2. OutOfMemoryError：Java heap space
heap是Java内存中的堆区，主要用来存放对象，当对象太多超出了空间大小，GC又来不及释放的时候，就会发生溢出错误。即内存泄漏越来越严重时，可能会发生内存溢出。
解决方案：
3. StackOverFlowError
stack是Java内存中的栈空间，主要用来存放方法中的变量，参数等临时性的数据的，发生溢出一般是因为分配空间太小，或是执行的方法递归层数太多创建了占用了太多栈帧导致溢出。
解决方案：修改配置参数-Xss参数增加线程栈大小之外，优化程序是尤其重要。
引起内存溢出的原因有很多种，列出常见的几种如下所示：
那么内存溢出常见的解决方案有哪些呢？
内存泄漏是堆中的存在无用但可达的对象，GC无法回收。
内存溢出是空间不足的溢出，主要分为PermGen space不足、堆不足、栈不足。
高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。
高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。
响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。
吞吐量：单位时间内处理的请求数量。
QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。
并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。
互联网分布式架构设计，提高系统并发能力的方式，方法论上主要有两种：垂直扩展和水平扩展。
垂直扩展提升单机处理能力。垂直扩展的方式又有两种：
在互联网业务发展非常迅猛的早期，如果预算不是问题，强烈建议使用“增强单机硬件性能”的方式提升系统并发能力，因为这个阶段，公司的战略往往是发展业务抢时间，而“增强单机硬件性能”往往是最快的方法。不管是提升单机硬件性能，还是提升单机架构性能，都有一个致命的不足：单机性能总是有极限的。所以互联网分布式架构设计高并发终极解决方案还是水平扩展。
水平扩展：只要增加服务器数量，就能线性扩充系统性能。水平扩展对系统架构设计是有要求的，如何在架构各层进行可水平扩展的设计，以及互联网公司架构各层常见的水平扩展实践，是本文重点讨论的内容。
常见互联网分布式架构如上，分为：
反向代理层的水平扩展：
反向代理层的水平扩展，是通过“DNS轮询”实现的：dns-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问dns-server，会轮询返回这些ip。当nginx成为瓶颈的时候，只要增加服务器数量，新增nginx服务的部署，增加一个外网ip，就能扩展反向代理层的性能，做到理论上的无限高并发。
站点层的水平扩展：
站点层的水平扩展，是通过“nginx”实现的。通过修改nginx.conf，可以设置多个web后端。当web后端成为瓶颈的时候，只要增加服务器数量，新增web服务的部署，在nginx配置中配置上新的web后端，就能扩展站点层的性能，做到理论上的无限高并发。
服务层的水平扩展：
服务层的水平扩展，是通过“服务连接池”实现的。站点层通过RPC-client调用下游的服务层RPC-server时，RPC-client中的连接池会建立与下游服务多个连接，当服务成为瓶颈的时候，只要增加服务器数量，新增服务部署，在RPC-client处建立新的下游服务连接，就能扩展服务层性能，做到理论上的无限高并发。如果需要优雅的进行服务层自动扩容，这里可能需要配置中心里服务自动发现功能的支持。
数据层的水平扩展：
在数据量很大的情况下，数据层（缓存，数据库）涉及数据的水平扩展，将原本存储在一台服务器上的数据（缓存，数据库）水平拆分到不同服务器上去，以达到扩充系统性能的目的。
互联网数据层常见的水平拆分方式有这么几种，以数据库为例：
这里需要注意的是，通过水平拆分来扩充系统性能，与主从同步读写分离来扩充数据库性能的方式有本质的不同。通过水平拆分扩展数据库性能：
通过主从同步读写分离扩展数据库性能：
缓存层的水平拆分和数据库层的水平拆分类似，也是以范围拆分和哈希拆分的方式居多，就不再展开。
高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。
提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。前者垂直扩展可以通过提升单机硬件性能，或者提升单机架构性能，来提高并发性，但单机性能总是有极限的，互联网分布式架构设计高并发终极解决方案还是后者：水平扩展。
互联网分层架构中，各层次水平扩展的实践又有所不同：
参考文章
原文：https://www.cnblogs.com/lijianming180/p/12375817.html