Tomcat 服务器的配置主要集中于 tomcat/conf 下的 catalina.policy、catalina.properties、context.xml、server.xml、tomcat-users.xml、web.xml 文件。
server.xml
server.xml 是 Tomcat 服务器的核心配置文件，包含了 Tomcat 的 Servlet 容器（Catalina）的所有配置。由于配置的属性特别多，我们在这里主要讲解其中的一部分重要配置。
Server
<Server port="8005" shutdown="SHUTDOWN">
<Service> ...</Service>
....
</Server>
其中 Server 用于监听 8005 端口， 监听 " shutdown " 命令，为了安全起见， 将不要使用默认值，可以将端口号改为 -1， 或者将 " shutdown " 口令改复杂一点， 否则容易遭到恶意攻击，比如 ： 我直接使用 telnet IP 8005 连接成功后 (前提是你要开放 8005 号端口）， 发出 " SHUTDOWN " 命令， 你的 Tomcat 就会直接停止
Listenner
<!‐‐ 用于以日志形式输出服务器 、操作系统、JVM的版本信息 ‐‐>
<Listener className="org.apache.catalina.startup.VersionLoggerListener"/>
<!‐‐ 用于加载（服务器启动） 和 销毁 （服务器停止） APR。 如果找不到APR库， 则会输出日志， 并不影响Tomcat启动 ‐‐>
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<!‐‐ 用于避免JRE内存泄漏问题 ‐‐>
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<!‐‐ 用户加载（服务器启动） 和 销毁（服务器停止） 全局命名服务 ‐‐>
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
<!‐‐ 用于在Context停止时重建Executor 池中的线程， 以避免ThreadLocal 相关的内存泄漏 ‐‐>
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
这个在前面将 Tomcat 的启动的时候，就已经提过了
GlobalNamingResources
<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
GlobalNamingResources 中定义了全局命名服务
Service
该元素用于创建 Service 实例，默认使用 org.apache.catalina.core.StandardService。 默认情况下，Tomcat 仅指定了 Service 的名称， 值为 “Catalina”。
Service 可以内嵌的 元素为 ： Listener、Executor、Connector、Engine，其中 ： Listener 用于为Service 添加生命周期监听器， Executor 用于配置 Service 共享线程池，Connector 用于配置 Service 包含的链接器， Engine 用于配置Service中链接器对应的Servlet 容器引擎。
Executor
它配置在 <Service> 标签中, 可以配置多个属性, 见下表
| 属性 | 含义 |
|---|---|
| name | 线程池名称，用于 Connector 中指定 |
| namePrefix | 所创建的每个线程的名称前缀，一个单独的线程名称为 namePrefix+threadNumber |
| maxThreads | 池中最大线程数 |
| minSpareThreads | 活跃线程数，也就是核心池线程数，这些线程不会被销 毁，会一直存在 |
| maxIdleTime | 线程空闲时间，超过该时间后，空闲线程会被销毁，默 认值为6000（1分钟），单位毫秒 |
| maxQueueSize | 在被执行前最大线程排队数目，默认为Int的最大值，也 就是广义的无限。除非特殊情况，这个值不需要更改， 否则会有请求不会被处理的情况发生 |
| prestartminSpareThreads | 启动线程池时是否启动 minSpareThreads部分线程。 默认值为false，即不启动 |
| threadPriority | 线程池中线程优先级，默认值为5，值从1到10 |
| className | 线程池实现类，未指定情况下，默认实现类为 org.apache.catalina.core.StandardThreadExecutor。 如果想使用自定义线程池首先需要实现 org.apache.catalina.Executor接口 |
每个 Connector 的线程池都是私有的, 可以使用指定线程池, 达到共用的效果
Connector
Connector 用于创建链接器实例。默认情况下，server.xml 配置了一个链接器，一个支持 HTTP 协议，一个支持 AJP 协议。因此大多数情况下，我们并不需要新增链接器配置， 只是根据需要对已有链接器进行优化
<Connector port="8080" protocol="HTTP/1.1" URIEncoding="UTF-8"
connectionTimeout="20000"
redirectPort="8443" />
属性说明 :
-
port： 端口号，Connector 用于创建服务端Socket 并进行监听， 以等待客户端请求链接。
如果该属性设置为 0，Tomcat 将会随机选择一个可用的端口号给当前 Connector 使用。
-
protocol ： 当前 Connector 支持的访问协议。
默认为 HTTP/1.1 ， 并采用自动切换机制选择一个基于NIO 的链接器或者基于本地 APR的链接器（根据本地是否含有 Tomcat 的本地库判定）
如果不希望采用上述自动切换的机制， 而是明确指定协议， 可以使用以下值。 -
connectionTimeOut : Connector 接收链接后的等待超时时间
单位为 毫秒, -1 表示不超时。
-
redirectPort：重定向端口
当前 Connector 不支持 SSL 请求， 接收到了一个请求， 并且也符合security-constraint 约束， 需要SSL传输，Catalina 自动将请求重定向到指定的端口。
-
executor ： 指定共享线程池的名称
可以通过maxThreads、minSpareThreads等属性配置内部线程池。
-
URIEncoding : 用于指定编码URI的字符编码
Tomcat8.x版本默认的编码为 UTF-8 , Tomcat7.x版本默认为ISO-8859-1。
太多了, 懒得写, 有需要请直接参照 : server.xml 配置
还有 Web 应用程序的 web.xml : web.xml 配置
session 共享
在 Tomcat 集群中，如果应用需要用户进行登录，那么这个时候，用于 Nginx 做了负载均衡，就会出现问题，比如同一个 IP 的请求可能会被不同 Tomcat 处理，可能就会重复登陆， 这种情况在实际生产环境下是不允许的，有以下几种解决方案 ：
ip_hash
根据 IP 地址计算出一个 hash 值，根据 hash 值来判断分配给哪台服务器，从而将来自同一 ip 的请求都分配到指定的服务器
优点
- 配置简单，对应用无侵入性，不需要修改代码
- 只要 hash 属性是均衡的，多台服务器的负载就是是均衡的
- 便于与服务器水平拓展
- 安全较高
缺点
- 服务器重启会照成部分 session 丢失
- 水平拓展过程中也会照成部分 session 丢失
- 存在单点负载过高的风险
session复制
这个解决方案其实就是当用户请求的时候，把产生的 sessionID 给复制到系统所有的服务器中，这样就能保证所有服务器都有该用户的 sessionID
优点
- 配置简单，对应用无侵入性，不需要修改代码
- 能适应各种负载均衡策略
- 服务器重启或宕机不会照成 session 丢失
- 安全较高
缺点
- session 同步存在一定的延时
- 占用内网带宽资源
- 受限于内存资源，水平拓展能力差
- 服务器数量较多时不好办
- 序列化反序列化消耗 CPU
高速缓存 redis
在用户的请求的时候， 把生成的 sessionID 给放到 Redis 的服务器上。然后在基于Redis 的特性进行设置一个失效时间的机制，这样就能保证用户在 Redis 中的 session失效时间内，都不需要进行再次登录
优点
- 能适应各种负载均衡策略
- 服务器重启或宕机不会照成 session 丢失
- 安全较高，拓展能力强
- 适合集群数量大时使用
缺点
- 对应用有侵入性，需要增加相关配置
- 增加一次网络开销，响应速度有一定影响
- 序列化反序列化消耗 CPU
数据 MySQL
session 保持在数据库，加重了数据库的IO，增大数据库的压力和负担，从而影响数据库的读写性能，而且mysql集群的话也不利于session的实时同步
使用 Cookie
把 session 放到 cookie 中去，因为每次用户请求的时候，都会把自己的 cookie 放到请求中，所以这样就能保证每次用户请求的时候都能保证用户在分布式环境下，也不会在进行二次登陆。
优势
这种方法简单易实现，可用性高，支持服务器横向拓展，方案成熟
缺点
安全性问题 （有可能被攻击者获取），Cookie 有大小限制，而且每次请求传输 Cookie 会影响性能，有些用户会禁用 Cookie，导致 session 失效，是下下策之举
Tomcat 管理
前面提到过, 需要修改 Server 监听的 8005 端口, 除此之外, Tomcat 出厂自带了四个 Web 应用, 请直接删除他们
从早期的 Tomcat 版本开始，就提供了 Web 版的管理控制台，他们是两个独立的 Web 应用，位于 webapps 目录下。Tomcat 提供的管理应用有用于管理的 Host 的 host-manager 和用于管理 Web 应用的 manager, 在实际生产过程中, 用处基本不大, 且存在安全隐患, 不如直接将其全部删除
host-manager
Tomcat 启动之后，可以通过 http://localhost:8080/host-manager/html 访问该 Web 应用。 host-manager 默认添加了访问权限控制，当打开网址时，需要输入用户名和密码 （conf/tomcat-users.xml中配置） 。所以要想访问该页面，需要在 conf/tomcatusers.xml 中配置，并分配对应的角色
<tomcat-users>
<role rolename="admin-gui"/>
<role rolename="admin-script"/>
<user username="root" password="yy120511" roles="admin-gui,admin-script"/>
</tomcat-users>
manager
manager 的访问地址为 http://localhost:8080/manager， 同样， manager 也添加了页面访问控制，因此我们需要为登录用户分配角色为
<tomcat-users>
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<user username="root" password="yy120511" roles="manager-gui,manager-script"/>
</tomcat-users>
错误页面
在 webapps/ROOT 目录下定义错误页面 404.html，500.html，然后 conf/web.xml 中进行配置 ， 配置错误页面
<error‐page>
<error‐code>404</error‐code>
<location>/404.html</location>
</error‐page>
<error‐page>
<error‐code>500</error‐code>
<location>/500.html</location>
</error‐page>
这样配置之后，用户在访问资源时出现 404,500 这样的异常，就能看到我们自定义的错误页面，而不会看到异常的堆栈信息，提高了用户体验，也保障了服务的安全性