转载：
https://www.cnblogs.com/kismetv/p/7228274.html#title1
http://blog.csdn.net/weinianjie1/article/details/7954425
一、前言
Tomcat是开源的轻量级Web应用服务器。server.xml中的每个元素都对应tomcat中的一个组件；通过对xml文件中元素的配置，可实现对tomcat中各个组件的控制。
二、元素分类和整体结构
1.server.xml整体结构
2.元素分类
server.xml中的元素可分为以下四类：
1）顶层元素：
2）连接器：
代表了外部客户端发送请求到特定Service的接口；同时也是外部客户端从特定Service接受响应的接口。
3）容器：
容器的功能是处理Connector接受进来的请求，并产生相应的响应。这三者是父子关系。一个Engine可处理Service中的所有请求，一个Host可处理发向一个特定虚拟主机的所有请求，一个Context组件可处理一个特定Web应用的所有请求。
4）内嵌组件：可内嵌到容器中的组件。以上6个是tomcat最核心的组件，其他组件都归为内嵌组件。
三、核心组件
1.Server
代表整个tomcat容器。一个Server元素中可以有一个或多个Service元素。Server的主要任务，就是提供一个接口让客户端能访问到这个Service集合，同时维护它所包含的所有的Service的生命周期。
shutdown属性：关闭Server的指令；
port属性：Server接受shutdown指令的端口，设为-1可禁掉该端口
2.Service
作用是把Connector和Engine组装在一起，对外提供服务。一个Service可包含多个Connector，但只能包含一个Engine；Connector的作用是从客户端接受请求，Engine的作用是处理接受进来的请求。
3.Connector
主要作用是接受连接请求，创建Request和Response对象用于和请求端交换数据；然后分配线程让Engine来处理这个请求，并把产生的Request和Response对象传给Engine。
通过配置Connector，可控制请求Service的协议及端口号。
1）举例1：
客户端可以通过8080端口使用http协议访问tomcat，protocol属性规定了请求的协议，port规定了请求的端口号，redirectPort表示强制要求https而请求是http时，重定向至端口号为8443的Connector。
2）举例2：
客户端可以通过8009端口使用AJP协议访问Tomcat。AJP协议负责和其他的HTTP服务器(如Apache)建立连接；在把Tomcat与其他HTTP服务器集成时，就需要这个连接器。
4.Engine
Engine组件是Service组件中的请求处理组件。在Service组件中有且只有一个。Engine组件从一个或多个Connector中接受请求并处理，并将完成的响应返回给Connector，最终传递给客户端。
name：用于日志和错误信息，在整个Server中应该唯一。
defaultHost：指定了默认的host名称，当发往本机的请求指定的host名称不存在时，一律使用defaultHost指定的host进行处理；因此，defaultHost的值，必须与Engine中的一个Host组件的name属性值匹配。
5.Host
1）Engine与Host
Host是Engine的子容器。Engine组件中可以内嵌一个或多个Host组件，每个Host组件代表Engine中的一个虚拟主机。Host组件至少有一个，且其中一个的name必须与Engine组件的defaultHost属性相匹配。
2）Host的作用
Host虚拟主机的作用，是运行多个Web应用(一个Context代表一个Web应用 )，并负责安装、展开、启动和结束每个Web应用。
Host组件代表的虚拟主机，对应了服务器中一个网络名实体(如"www.test.com"或IP地址"116.25.25.25")，为了使用户可以通过网络名连接Tomcat服务器，这个名字应该在DNS服务器上注册。
客户端通常用主机名来标识他们希望连接的服务器；该主机名也会包含在HTTP请求头中。Tomcat从HTTP头中提取主机名，寻找名称匹配的主机。如果没有匹配，请求将转发至默认主机。因此默认主机不需要再DNS服务器中注册。
3）Host的配置
name：虚拟主机名。一个Engine中有且仅有一个Host组件的name属性与Engine组件的defaultHost属性相匹配；
unpackWARs：是否将代表Web应用的WAR文件解压；true：通过解压后的文件结构运行该Web应用；false：直接使用WAR文件运行web应用；
Host的autoDeploy和、APPBase、xmlBase、deployOnStartup属性，与Host内Web应用的自动部署有关。
6.Context
1）Context元素代表在特定虚拟主机上运行的一个Web应用。每个Web应用基于war文件或war文件解压后对应的目录。
Context是Host的子容器，每个Host可以定义任意多个Context元素。
2）Web应用自动部署
（1）Host的配置
要开启Web应用的自动部署，需要配置所在的虚拟主机；配置方式就是前面提到的Host元素的deployOnStartup和autoDeploy属性。如果这俩属性设为true，则tomcat启动自动部署。二者主要区别在于，deployOnStartup为true时，tomcat在启动时检查web应用；autoDeploy为true时，tomcat在运行时定期检查新的web应用或web应用的更新。
自动部署依赖于检查是否有新的或更改过的web应用，而Host元素的appBase和xmlBase设置了检查web应用更新的目录。
appBase：指定web应用所在的目录，默认值是webapps，这是一个相对路径。
xmlBase：指定web应用的XML配置文件所在的目录。默认值为conf/
（2）检查web应用更新
一个web应用可能包含以下文件：XML配置文件，WAR包，以及一个应用目录(该目录包含Web应用的文件结构)；其中XML文件位于xmlBase指定的目录，WAR包和应用目录位于appBase指定的目录。tomcat会扫描这俩属性配置的目录来检查应用更新。
（3）
docBase：指定web应用使用的war包路径，或应用目录。需注意的是：在自动部署场景下(配置文件位于xmlBase中)，docBase不在appBase目录中，才需要指定。
path：指定了访问该web应用的上下文路径，当请求到来时，tomcat根据web应用的path属性与URI的匹配程度来选择web应用处理相应请求。如果一个Context元素的path属性为""，则这个Context是虚拟主机的默认web应用；当请求的URI与所有path都不匹配时，使用该默认web应用来处理。
需要注意的是，在自动部署场景下（配置文件位于xmlBase中），不能指定path属性，path属性由配置文件的文件名、war文件的文件名或应用目录的名称自动推导出来。如扫描web应用时，发现了xmlBase目录下的app1.xml，或appBase目录下的app1.war或app1应用目录，则该web应用的path属性为"app1"。如果名称不是app1而是ROOT，则该web应用是虚拟主机默认的web应用，此时path属性推导为""。
reloadable：指示tomcat是否在运行时监控在WEB-INF/classes和WEB-INF/lib目录下的class文件的改动。若为true，则当class文件改动时会触发web应用重新加载。开发环境设为true方便调试；生产环境设为true会给服务器带来性能压力。
（4）自动部署举例
最典型的自动部署，就是当我们安装完tomcat后，在webapps目录下有如下文件夹：
当启动tomcat后，可用http://localhost:8080/来访问tomcat，其实访问的就是ROOT对应的web应用；也可通过http://localhost:8080/docs来访问docs应用，同理可访问examples/host-manager/这几个web应用。
http://localhost:8080/：ROOT是tomcat中的一个项目，最后的“/”表示http的根-ROOT。
3）server.xml中静态部署web应用
除了自动部署，我们也可以在server.xml中通过
docBase：静态部署时，docBase可以在appBase目录下，也可不在。
path：静态部署时，可显示指定path属性，但仍受到严格限制：只有当自动部署关闭(deployOnStartup和autoDeploy都为false)或docBase不在appBase中时，才可设置path。
reloadable：用法与自动部署时相同。
四、配置多个服务
通过在Server中配置多个Service服务，可以实现通过不同的端口号来访问同一台机器上部署的不同Web应用。
五、其他组件
1.Listener
监听器。可在特定事件发生时执行特定的操作；被监听事件通常是tomcat的启动和停止。
2.GlobalNamingResources与Realm
Realm，可以把它理解成“域”；Realm提供了一种用户密码与web应用的映射关系，从而达到角色安全管理的作用。
3.valve
阀门。在Tomcat中代表了请求处理流水线上的一个组件；Valve可以与Tomcat的容器(Engine、Host或Context)关联。
不同的Valve有不同的特性，下面介绍一下本例中出现的AccessLogValve。
AccessLogValve的作用是通过日志记录其所在的容器中处理的所有请求，在本例中，Valve放在Host下，便可以记录该Host处理的所有请求。AccessLogValve记录的日志就是访问日志，每天的请求会写到一个日志文件里。AccessLogValve可以与Engine、Host或Context关联；在本例中，只有一个Engine，Engine下只有一个Host，Host下只有一个Context，因此AccessLogValve放在三个容器下的作用其实是类似的。
本例的AccessLogValve属性的配置，使用的是默认的配置；下面介绍AccessLogValve中各个属性的作用：
（1）className：规定了Valve的类型，是最重要的属性；本例中，通过该属性规定了这是一个AccessLogValve。
（2）directory：指定日志存储的位置，本例中，日志存储在$TOMCAT_HOME/logs目录下。
（3）prefix：指定了日志文件的前缀。
（4）suffix：指定了日志文件的后缀。通过directory、prefix和suffix的配置，在$TOMCAT_HOME/logs目录下，可以看到如下所示的日志文件。
（5）pattern：指定记录日志的格式
pattern的配置中，有一个非常有用的选项是%D，含义是请求处理的时间(单位是毫秒)，对于统计分析请求的处理速度帮助很大。
开发人员可以充分利用访问日志，来分析问题、优化应用。例如，分析访问日志中各个接口被访问的比例，不仅可以为需求和运营人员提供数据支持，还可以使自己的优化有的放矢；分析访问日志中各个请求的响应状态码，可以知道服务器请求的成功率，并找出有问题的请求；分析访问日志中各个请求的响应时间，可以找出慢请求，并根据需要进行响应时间的优化。
六、关于用tomcat部署多个应用的3种方法:
1.配置文件中使用多个Context元素。这种配置好处是这些应用公用Connector，也就是说访问端口是一样的，这样就可以都部署在80下了。
这样有一个要求，就是应用程序在设计的时候就支持Context，一些链接前面都先加上动态的应用名，而不是使用“/”这样的绝对路径。Context元素的path一定不要以“/”结尾，可以是""或者"/WEB1"这样的。
2.配置文件中使用多个Service元素。这种配置可以解决应用程序不支持动态应用名的情况，使用不同端口访问不同页面。
不过这样有时候也不是很顺利，由于一个tomcat的jvm对一个jni类只允许load一次，你多个应用如果同时load了某个jni的类则会部署失败。这种情况可以把这个类从项目里拿出来放到tomcat安装目录的lib下作为公用的。不过还是有点麻烦哈~
3.部署多个tomcat。这个一般是做集群的时候用的，不过你也可以用来部署多应用，只要调整下端口不冲突就行。