Tomcat 之图文解析 Server.xml 配置

本文即将介绍的是Server.xml - Tomcat的主配置文件。该文件存放在安装目录下的conf文件夹中。为了让大家有个直观的认识，在此将Tomcat7的默认配置摘录如下：

去掉元素属性，稍加整理，配置文件就变成了下面这样：

根据Tomcat自身的分类，上面这些元素可以分成四种：

下面将选择性地介绍这些元素。

Server

一个Tomcat只有一个Server.xml，即一个Tomcat实例只有一个Server。从实现来看，作为Server.xml的根节点，它不是一个容器，它只是单纯地扮演着一个包裹的角色。从命名来看，它又可以是整个Tomcat所有容器和作用于所用容器的组件的混合体。在此，我们把它当做是Tomcat实例本身。

★ 单机Tomcat实例个数

大部分情况下我们在一台服务器/云服务器上只跑一个tomcat，但也有 两种特例 ：

一是 为了测试，在一台机器上跑多个Tomcat，用以模拟多台服务器多个应用交互的效果。

二是 通过nginx+多个tomcat组成负载均衡集群，以达到以下目的：

★ Server元素属性

Server可配置的属性很少。根据上面摘录的默认配置，Server会侦听localhost的TCP端口8005，当该端口接收到字符串"SHUTDOWN"时，即执行关闭Tomcat操作。

★ Server 的嵌套组件

Server有两种特有的组件，一个是GlobalNamingResources（全局命名资源），一个是Service（服务）。除此之外，还可以有Listener（监听器）这种可以作用于不同层次容器的组件。Server默认配置了六种Listener，其作用会在后面介绍。配置在Server这一层的Listener对所有容器起作用。

Service

Service是另一个混合体。一个Service就是一个完整的服务，负责将若干个Connector和一个Engine（引擎）包裹在一起。除此之外，Service还可以配置一个Executor（共享线程池）用于管理所有Connector的线程数量。

★ service元素属性

Service的属性比Server更少，一般只用到了name这个属性。默认配置定义了一个名为“Catalina”的 Service。什么是Catalina呢？Cataline是一个太平洋小岛的名字，而Tomcat开发团队的一个核心人员Craig McClanahan喜欢这个小岛，所以...

★ Service 的嵌套组件

如图所示，Service有Executor、Connector和Engine三种组件。其中，每个Connector负责侦听一个TCP端口，接收相应的请求，并转发给绑定的Engine处理。Engine处理完后，通过Connector把结果返回给客户端。在配置了Executor的情况下，所有Connector的线程受Executor统一管理。

Tomcat里有四种层次的容器：Engine、Cluster、Host、Context，

从属关系为：

Context -> (Cluster in Host) -> Host -> (Cluster in Engine) -> Engine

具体关系如下图所示：

E ngine容器

Engine是Service的请求处理引擎，负责处理所有Connector发过来的请求，并将内部处理完毕的结果返回给Connector。它是最外层的容器。

★ Engine元素属性

■ Engine.name - 引擎的名称

默认配置定义了一个Engine，和外层的Service一样，也叫Catalina。反正一个Service只有一个Engine，这么起名问题也不大。

■ Engine.defaultHost - 默认采用哪一个子容器Host来处理请求

■ Engine.jvmRoute - 一个用于负载均衡场景下的唯一标识符

默认的负载均衡场景下，Tomcat采用一种被称作粘性session的机制管理session信息。

粘性session就是将用户“粘”在其中一个Engine上。比方说，客户端刚访问进来时被Nginx转发到Engine#1并完成了登录验证，那么接下来的每次请求都应该转发到这个Engine。如果该机制失效，客户端的后续访问被Nginx转发到Engine#2的话，由于Engine#2并没有该客户端的session信息，将会要求重新登录。

为了实现粘性session，Engine需要告诉Nginx，某一个session是我处理的，后续这个session都要发给我。方法就是给Engine定义一个唯一的jvmRoute，附在它受理的sessionID上，再返回给Nginx。例如，配置jvmRote="Engine#1"。

★ Engine上下文配置

每一个Engine都在安装目录的conf文件夹下有一个对应的二级目录，例如默认的conf/cataline。相应的，Engine下的每一个Host，都会在Engine对应的二级目录下有一个三级目录，例如默认的conf/cataline/localhost。其路径规则为：

作用于整个Engine或整个Host的上下文信息可以配置在这些个目录中。该目录可以通过相应容器的xmlBase属性进行修改。

Host 容器

一个Host就是一个虚拟主机，对应一个或多个域名。

★ Host元素属性

■ Host.name - 主机名称（域名）

默认配置定义了一个名为 localhost 的主机。至少要有一个Host的名称与Engine的defaultHost一致。

除了域名外，Host可以通过子节点alias来配置别名。别名的作用与域名一致。例如：

其作用机制如下图所示：

■ Host.appBase - 虚拟主机的根目录

该参数的默认值为webapps。一般情况下，每一个 webapp 的 URL 和它所在的目录名称相同。以webapps目录下的manager和docs两个程序为例（ROOT是个例外）：

■ Host.unpackWARs - 放到 webapps 目录下的 WAR-file 是否应该被解压

如设为false，Tomcat 将会直接从 *.war文件运行应用，但可能导致应用运行变慢。

■ Host.autoDeploy - 是否自动部署放到 webapps 目录下的应用

Context 容器

Context代表Host下面的一个虚拟目录。

在不配置Context的情况下是这样的：

现在配置一个Context，同样访问博客域名，就变成了访问"D:/mzdbxqh"

★ Context元素属性

■ Context.docBase - 应用程序的路径或者是WAR文件存放的路径

■ Context.path - 此web应用程序的上下文路径

配置后，Context的访问url为：http://localhost:8080/path/

path为空的话，访问url为：http://localhost:8080/

■ Context.reloadable - 是否支持热部署

如果为true，则tomcat会自动检测应用程序的/WEB-INF/lib 和/WEB-INF/classes目录的变化，并通过类加载器重新加载class文件，以实现在不重启tomcat的情况下重新部署。

因为配置文件基本是在web程序启动时一次性载入内存的，故一般来说Tomcat的热部署对配置文件无效。另外，只有新创建实例时才会向类加载器请求重新加载过的class，因此，Tomcat的热部署对于使用Spring管理的单例也是无效的。这两种情况需要web应用程序配合着写热部署的业务逻辑才能实现。

■ Context.crossContext - 不同context是否共享session

注意，这个跨应用共享session跟Cluster集群是不一样的。前者是指可以通过ServletContext.getContext()交叉访问其他Context的session，后者默认配置下是采用服务器session复制的方式，将每一个节点的session变动复制到所有节点。

Cluster容器

Tomcat的Cluster是一个集群容器。它的集群策略是复制session，把集群内一个容器的session变动通过广播复制到其他所有容器上。Cluster可配置在Engine或Host内。

此外，复制session的模式因为对网络（广播复制）和内存（每一个JVM实例都要保存所有在线用户的session）的负担较大，在大型分布式场景下一般采用session共享的方式。具体可以了解一下Spring Session。以上三种session管理方式的对比如下图所示：

Connector组件

开头说过，Connector就是墙上的插座，负责侦听一个具体的TCP端口，并通过该端口处理Engine与客户端之间的交互。默认配置定义了两个 Connector：

更多Connector和Executor线程池的配置会在Tomcat性能调优的章节进行说明。

Valve组件

Valve的中文含义是阀门，可以简单地理解为Tomcat的拦截器。它负责在请求发送到应用之前拦截HTTP请求，可以定义在任何容器中。默认配置中定义了一个AccessLogValve，负责拦截HTTP请求，并写入到日志文件中。

Listener组件

Listener即监听器，负责监听服务器端的行为。此处需要了解的监听器有两个：