参考学习：
http://www.zslin.com/web/article/detail/23
http://blog.csdn.net/catoop/article/details/50501706

诉求：Spring Boot 默认为我们提供了静态资源处理，而有时我们需要自定义资源映射，可定义项目内部目录，也可定义外部目录。此处举例外部目录映射配置。

方法一：通过配置文件配置

在Springboot中可以直接在配置文件中覆盖默认的静态资源路径的配置信息:
作用在application.yml或application.properties
首先系统有默认配置,其中默认配置的 /** 映射到 /static （或/public、/resources、/META-INF/resources）

默认大概意思如下所示(为了和下面进行对比)：
spring:
    mvc:
        static-path-pattern: /**
    resources:
         static-locations: classpath:/META-INF/resources/,classpath:/resources/, classpath:/static/, classpath:/public/

定义 static-path-pattern: /** ，会覆盖默认配置,需要在static-locations添加默认的内部目录和自定义目录，应为

添加自定义外部目录并覆盖默认
spring:
    mvc:
        static-path-pattern: /**
    http:
        multipart:
            location: F://preview
    resources:
        static-locations: classpath:/META-INF/resources/,classpath:/resources/, classpath:/static/, classpath:/public/, file:${spring.http.multipart.location}

如果定义 static-path-pattern: /we/**,则访问static-locations里目录时都应加上”/we/”
spring.mvc.static-path-pattern 只可以定义一个，目前不支持多个逗号分割的方式，

方法二：通过@Configuration配置

@Configuration
public class ApplicationConfig extends WebMvcConfigurerAdapter {

    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        /**
         * 如果我们将/xxxx/** 修改为 /** 与默认的相同时，则会覆盖系统的配置，可以多次使用 addResourceLocations 添加目录，
         * 优先级先添加的高于后添加的。
         *
         * 如果是/xxxx/** 引用静态资源 加不加/xxxx/ 均可，因为系统默认配置（/**）也会作用
         * 如果是/** 会覆盖默认配置，应用addResourceLocations添加所有会用到的静态资源地址，系统默认不会再起作用
         */
        registry.addResourceHandler("/**")
                .addResourceLocations("classpath:/META-INF/resources/")
                .addResourceLocations("classpath:/resources/")
                .addResourceLocations("classpath:/static/")
                .addResourceLocations("classpath:/public/");
        registry.addResourceHandler("/we/**").addResourceLocations("file:F:/preview/");
        super.addResourceHandlers(registry);
    }
}

此方法直接写在代码内，同方法一一样，可以覆盖默认配置，添加自定义映射配置，也可以只添加自定义映射配置，不覆盖默认配置。方法二比之方法一更为灵活。

目前SpringBoot被各企业广泛使用，在SpringBoot结合Mybatis使用时，有的人将mapper.xml 存放到resouce的目录下，有的想把Mapper.xml 和接口放到一起，但是这样/就会存在Mapper.xml加载不了，导致方法无法找到，现在咱们看看两种方式的配置。

首先说第一种：

也就是网上说的最多的一种，添加依赖，我就不细说了。

1.在application.properties 中添加对xml中对实体对象引用的配置

2.在application.properties 添加xml在resouces目录下的位置

如下图

mybatis.type-aliases-package=com.gao.security.bean
mybatis.mapper-locations=classpath:mybatis/mapper/*.xml

目录结构如下

3.在springboot 主入口添加注解，里面值为Mapper对应的Java接口类

@MapperScan("com.gao.security.dao")

然后第一种配置方式就结束了，你可以正常使用mabatis了。

接下来，咱们再说第二种，第二种先对更简单些

优点：无需在application.properties  添加第一种的那种配置，也不用在springboot主入口添加MapperScan注解

具体配置：

1.将Mapper和Java接口存放一个目录，如下

2.只需要在pom.xml 中的build标签中添加resouce资源的配置加载src/main/java 中的xml即可,如下图

<build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
        <resources>
            <resource>
                <directory>src/main/java</directory>
                <includes>
                    <include>**/*.xml</include>
                </includes>
            </resource>
            <resource>
                <directory>src/main/resources</directory>
            </resource>
        </resources>
    </build>

好了，现在两种方式都讲了，具体可以根据自己想法使用哪一种就可以了

YARN的资源调度主要针对的是内存(Memory)和CPU，并将其组合抽象成Container来管理分配。

在YARN中，资源管理由ResourceManager和NodeManager共同完成，其中，ResourceManager中的调度器负责资源的分配，而NodeManager则负责资源的供给和隔离。ResourceManager将某个NodeManager上资源分配给任务（这就是所谓的“资源调度”）后，NodeManager需按照要求为任务提供相应的资源，甚至保证这些资源应具有独占性，为任务运行提供基础的保证，这就是所谓的资源隔离。

在正式介绍具体的资源调度和隔离之前，先品味一下内存和CPU这两种资源的特点，这是两种性质不同的资源。内存资源的多少会会决定任务的生死，如果内存不够，任务可能会运行失败；相比之下，CPU资源则不同，它只会决定任务运行的快慢，不会对生死产生影响。

Memory配置

计算单台机器的Container上限值

containers = min (2*CORES, 1.8*DISKS, (Total available RAM) / MIN_CONTAINER_SIZE)

其中：

• CORES: 机器CPU核数
• DISKS: 机器上挂载的磁盘个数
• Total available RAM: 机器总内存
• MIN_CONTAINER_SIZE: Container最小的容量大小

MIN_CONTAINER_SIZE主要与机器可用的RAM有关：

YARN配置(内存相关)

• yarn.nodemanager.resource.memory-mb

表示该节点上YARN可使用的物理内存总量，默认是8192（MB）。

注意，如果你的节点内存资源不够8GB，则需要调减小这个值，而YARN不会智能的探测节点的物理内存总量。

• yarn.nodemanager.vmem-pmem-ratio

任务每使用1MB物理内存，最多可使用虚拟内存量，默认是2.1。

• yarn.nodemanager.pmem-check-enabled

是否启动一个线程检查每个任务正使用的物理内存量，如果任务超出分配值，则直接将其杀掉，默认是true。

• yarn.nodemanager.vmem-check-enabled

是否启动一个线程检查每个任务正使用的虚拟内存量，如果任务超出分配值，则直接将其杀掉，默认是true。

• yarn.scheduler.minimum-allocation-mb

单个container可申请的最少物理内存量，默认是1024（MB），如果一个任务申请的物理内存量少于该值，则该对应的值改为这个数。

• yarn.scheduler.maximum-allocation-mb

单个container可申请的最少物理内存量，默认是1024（MB），如果一个任务申请的物理内存量少于该值，则该对应的值改为这个数。

默认情况下，YARN采用了线程监控的方法判断任务是否超量使用内存，一旦发现超量，则直接将其杀死。由于Cgroups对内存的控制缺乏灵活性（即任务任何时刻不能超过内存上限，如果超过，则直接将其杀死或者报OOM），而Java进程在创建瞬间内存将翻倍，之后骤降到正常值，这种情况下，采用线程监控的方式更加灵活（当发现进程树内存瞬间翻倍超过设定值时，可认为是正常现象，不会将任务杀死），因此YARN未提供Cgroups内存隔离机制。

CPU配置

在YARN中使用的是虚拟CPU，虚拟CPU是YARN自己引入的概念，初衷是，考虑到不同节点的CPU性能可能不同，每个CPU具有的计算能力也是不一样的，比如某个物理CPU的计算能力可能是另外一个物理CPU的2倍，这时候，你可以通过为第一个物理CPU多配置几个虚拟CPU弥补这种差异。用户提交作业时，可以指定每个任务需要的虚拟CPU个数。在YARN中，CPU相关配置参数如下：

YARN配置(CPU相关)

• yarn.nodemanager.resource.cpu-vcores

表示该节点上YARN可使用的虚拟CPU个数，默认是8，注意，目前推荐将该值设值为与物理CPU核数数目相同。

如果你的节点CPU核数不够8个，则需要调减小这个值，而YARN不会智能的探测节点的物理CPU总数。

• yarn.scheduler.minimum-allocation-vcores

单个任务可申请的最小虚拟CPU个数，默认是1，如果一个任务申请的CPU个数少于该数，则该对应的值改为这个数。

• yarn.scheduler.maximum-allocation-vcores

单个任务可申请的最多虚拟CPU个数，默认是32。

默认情况下，YARN是不会对CPU资源进行调度的，你需要配置相应的资源调度器来支持。

资源划分方式

默认情况下，NodeManager不会对CPU资源进行任何隔离，你可以通过启用Cgroups让你支持CPU隔离。

由于CPU资源的独特性，目前这种CPU分配方式仍然是粗粒度的。举个例子，很多任务可能是IO密集型的，消耗的CPU资源非常少，如果此时你为它分配一个CPU，则是一种严重浪费，你完全可以让他与其他几个任务公用一个CPU，也就是说，我们需要支持更粒度的CPU表达方式。

借鉴亚马逊EC2中CPU资源的划分方式，即提出了CPU最小单位为EC2 Compute Unit（ECU），一个ECU代表相当于1.0-1.2 GHz 2007 Opteron or 2007 Xeon处理器的处理能力。YARN提出了CPU最小单位YARN Compute Unit（YCU），目前这个数是一个整数，默认是720，由参数yarn.nodemanager.resource.cpu-ycus-per-core设置，表示一个CPU core具备的计算能力（该feature在2.2.0版本中并不存在，可能增加到2.3.0版本中），这样，用户提交作业时，直接指定需要的YCU即可，比如指定值为360，表示用1/2个CPU core，实际表现为，只使用一个CPU core的1/2计算时间。注意，在操作系统层，CPU资源是按照时间片分配的，你可以说，一个进程使用1/3的CPU时间片，或者1/5的时间片。

参考文献：

1. http://dongxicheng.org/mapreduce-nextgen/hadoop-yarn-memory-cpu-scheduling/