nginx tomcat 是什么关系？

平级关系。

Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，并在一个BSD-like 协议下发行。由俄罗斯的程序设计师Igor Sysoev所开发，供俄国大型的入口网站及搜索引擎Rambler（俄文：Рамблер）使用。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：百度、新浪、网易、腾讯等。

Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，属于轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选。对于一个初学者来说，可以这样认为，当在一台机器上配置好Apache 服务器，可利用它响应HTML（标准通用标记语言下的一个应用）页面的访问请求。实际上Tomcat 部分是Apache 服务器的扩展，但它是独立运行的，所以当你运行tomcat 时，它实际上作为一个与Apache 独立的进程单独运行的。

Tomcat与Nginx、Apache的关系如下图。由配送中心选择Apache、Nginx中的某一辆货车将包裹送给客户。虽然Apache、Nginx两辆车的用途是一样的，仔细区分它们两还是有区别的，比如：货物装载的速度、方式不一样，Apache有水箱可以直接运送活鱼而Nginx没有。

Tomcat有点像装活鱼的特殊包装。经过特殊包装打包的活鱼就可以通过Nginx和Apache运送到用户手中。另外，使用Tomcat包含了一种慢速的配送服务，所以配送中心一般都采用Nginx、Apache等配送。通过上面的比方引申Apache、Nginx、Tomcat的实际用途Apache全称Apache

HTTP

Server，它是Apache软件基金会的一个开放源码的网页伺服服务器软件。

Apache支持模块多，性能稳定。Apache本身是静态解析（静态页面），适合静态的HTML、等，但可以通过扩展脚本、模块来支持动态页面等。Apche可以支持PHP、CGI、Perl，但要使用Java就需要Tomcat，Java请求会通过Apache转发给Tomcat处理；

Nginx同样也是一款开源的HTTP

Server，它是由俄罗斯人编写的轻量级HTTP服务。Nginx是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP、POP3、SMTP代理服务器。Nginx本身不支持生成动态页面，很大部分Web服务器使用Nginx，主要通过Nginx的反向代理来实现负载均衡器。

Apache、Nginx本质上就是一种运用在HTTP服务器上某种应用程序，它们通过绑定服务器的IP地址并监听某一个TCP端口来接收并处理HTTP请求，这样用户（一般通过IE、Chrome、Firefox等发送请求并显示内容）就能够通过HTTP协议来获取服务器上的网页（HTML+CSS样式）、文档（PDF、txt、rar等）、音频、视频等资源。如下图：

不仅Apache和Nginx，绝大多数编程语言所包含的类库中也可以实现简单的HTTP服务供开发者使用，如：Java HTTP Server、Python SimpleHTTPServer。Apache和Nginx的对比Nginx使用异步非阻塞型事件驱动的方法来处理请求，而Apache则是通过同步阻塞型的方法来处理请求。

Apache接收一个请求后，就会创建一个进程，每个进程内单线程。对于一个负载相对较高的网站来说，256的进程，也就是256个线程。线程处理请求时是同步阻塞模式，会一直等待该请求读取程序文件（IO）（同步），执行业务逻辑，返回给客户端，所有操作完成之后才能处理下一个请求（阻塞）。如果服务器已经达到256的极限，那么接下去的访问就需要排队。这也就是为什么某些服务器负载不高的原因了。

而Ngnix接收一个请求后，不会等待这个请求的文件读取操作完成之后才接收下一个请求，它不会等待这个请求的后续的处理结果。而是会马上循环处理下一个请求（不阻塞）。请求的程序文件执行完成之后，会主动通知该线程，不用你主动去等待或者轮询查看（异步）。

最后返回给客户端。这样做，每个请求过来就不需要等待很长的时间排队，而是马上就能接收，开始进行处理了。等处理完成之后，会主动通知回调这个线程进行数据返回。

基于上述特性Nginx更轻量级，比Apache占用更少的内存及资源抗并发，Nginx静态处理性能比Apache高3倍以上。在高并发下Nginx能保持低资源低消耗高性能高度模块化的设计。但Apache组件比Nginx多，对PHP的支持比较简单，Apche的Rewrite也比Nginx强大一些。Tomcat用于扩充Apache和Nginx的动态性能从上面我们知道了Apache和Nginx的优势在于静态解析，那么动态解析就会交给其他模块处理，如Tomcat。

Tomcat是由Apache软件基金会旗下Jakarta项目开发的Servlet容器，实现对Servlet和JavaServer Page（jsp）的支持。Tomcat本身也包含了HTTP服务，也可单做独立的Web服务，但用的不多。

Tomcat一共设计了

4

种容器，它们分别为Engine、Host、Context、Wrapper，各个容器组件之间的关系是由大到小，即父子关系，它们之间关系形成一个树状的结构，它们的实现类都实现了

Container

接口。总结如果Apache、Nginx、Tomcat打一局LOL，Apache和Nginx像是冲在最前面的英雄。而Tomcat攻击性能弱，它主要负责打辅助，奶前面的英雄。

Nginx并发性好，CPU、内存占用低。但如果rewrite频繁，那还是选择Apache好一些，Apache在处理动态请求更有优势。

CentOS（Community Enterprise Operating System，中文意思是：社区企业操作系统）是Linux发行版之一，它是来自于Red Hat Enterprise Linux依照开放源代码规定释出的源代码所编译而成。由于出自同样的源代码，因此有些要求高度稳定性的服务器以CentOS替代商业版的Red Hat Enterprise Linux使用。两者的不同，在于CentOS并不包含封闭源代码软件。

前言

Tomcat隶属于Apache基金会，是开源的轻量级Web应用服务器，使用非常广泛。serverxml是Tomcat中最重要的配置文件，serverxml的每一个元素都对应了Tomcat中的一个组件；通过对xml文件中元素的配置，可以实现对Tomcat中各个组件的控制。因此，学习serverxml文件的配置，对于了解和使用Tomcat至关重要。

本文将通过实例，介绍serverxml中各个组件的配置，并详细说明Tomcat各个核心组件的作用以及各个组件之间的相互关系。

说明：由于serverxml文件中元素与Tomcat中组件的对应关系，后文中为了描述方便，“元素”和“组件”的使用不严格区分。

一、一个serverxml配置实例

serverxml位于$TOMCAT_HOME/conf目录下；下面是一个serverxml实例。后文中将结合该实例讲解serverxml中，各个元素的含义和作用；在阅读后续章节过程中，可以对照该xml文档便于理解。

二、serverxml文档的元素分类和整体结构

1、整体结构

serverxml的整体结构如下：

该结构中只给出了Tomcat的核心组件，除了核心组件外，Tomcat还有一些其他组件，下面介绍一下组件的分类。

2、元素分类

serverxml文件中的元素可以分为以下4类：

（1）顶层元素：和

元素是整个配置文件的根元素，元素则代表一个Engine元素以及一组与之相连的Connector元素。

（2）连接器：

代表了外部客户端发送请求到特定Service的接口；同时也是外部客户端从特定Service接收响应的接口。

（3）容器：

容器的功能是处理Connector接收进来的请求，并产生相应的响应。Engine、Host和Context都是容器，但它们不是平行的关系，而是父子关系：Engine包含Host，Host包含Context。一个Engine组件可以处理Service中的所有请求，一个Host组件可以处理发向一个特定虚拟主机的所有请求，一个Context组件可以处理一个特定Web应用的所有请求。

（4）内嵌组件：可以内嵌到容器中的组件。实际上，Server、Service、Connector、Engine、Host和Context是最重要的最核心的Tomcat组件，其他组件都可以归为内嵌组件。

下面将详细介绍Tomcat中各个核心组件的作用，以及相互之间的关系。

三、核心组件

本部分将分别介绍各个核心组件的作用、特点以及配置方式等。

1、Server

Server元素在最顶层，代表整个Tomcat容器，因此它必须是serverxml中唯一一个最外层的元素。一个Server元素中可以有一个或多个Service元素。

在第一部分的例子中，在最外层有一个元素，shutdown属性表示关闭Server的指令；port属性表示Server接收shutdown指令的端口号，设为-1可以禁掉该端口。

Server的主要任务，就是提供一个接口让客户端能够访问到这个Service集合，同时维护它所包含的所有的Service的声明周期，包括如何初始化、如何结束服务、如何找到客户端要访问的Service。

2、Service

Service的作用，是在Connector和Engine外面包了一层，把它们组装在一起，对外提供服务。一个Service可以包含多个Connector，但是只能包含一个Engine；其中Connector的作用是从客户端接收请求，Engine的作用是处理接收进来的请求。

在第一部分的例子中，Server中包含一个名称为“Catalina”的Service。实际上，Tomcat可以提供多个Service，不同的Service监听不同的端口，后文会有介绍。

3、Connector

Connector的主要功能，是接收连接请求，创建Request和Response对象用于和请求端交换数据；然后分配线程让Engine来处理这个请求，并把产生的Request和Response对象传给Engine。

通过配置Connector，可以控制请求Service的协议及端口号。在第一部分的例子中，Service包含两个Connector：

在这个例子中，Tomcat监听HTTP请求，使用的是8080端口，而不是正式的80端口；实际上，在正式的生产环境中，Tomcat也常常监听8080端口，而不是80端口。这是因为在生产环境中，很少将Tomcat直接对外开放接收请求，而是在Tomcat和客户端之间加一层代理服务器(如nginx)，用于请求的转发、负载均衡、处理静态文件等；通过代理服务器访问Tomcat时，是在局域网中，因此一般仍使用8080端口。

（2）通过配置第2个Connector，客户端可以通过8009端口号使用AJP协议访问Tomcat。AJP协议负责和其他的HTTP服务器(如Apache)建立连接；在把Tomcat与其他HTTP服务器集成时，就需要用到这个连接器。之所以使用Tomcat和其他服务器集成，是因为Tomcat可以用作Servlet/JSP容器，但是对静态资源的处理速度较慢，不如Apache和IIS等HTTP服务器；因此常常将Tomcat与Apache等集成，前者作Servlet容器，后者处理静态资源，而AJP协议便负责Tomcat和Apache的连接。Tomcat与Apache等集成的原理如下图(来源)：

4、Engine

Engine组件在Service组件中有且只有一个；Engine是Service组件中的请求处理组件。Engine组件从一个或多个Connector中接收请求并处理，并将完成的响应返回给Connector，最终传递给客户端。

前面已经提到过，Engine、Host和Context都是容器，但它们不是平行的关系，而是父子关系：Engine包含Host，Host包含Context。

在第一部分的例子中，Engine的配置语句如下：

其中，name属性用于日志和错误信息，在整个Server中应该唯一。defaultHost属性指定了默认的host名称，当发往本机的请求指定的host名称不存在时，一律使用defaultHost指定的host进行处理；因此，defaultHost的值，必须与Engine中的一个Host组件的name属性值匹配。

5、Host

（1）Engine与Host

Host是Engine的子容器。Engine组件中可以内嵌1个或多个Host组件，每个Host组件代表Engine中的一个虚拟主机。Host组件至少有一个，且其中一个的name必须与Engine组件的defaultHost属性相匹配。

（2）Host的作用

Host虚拟主机的作用，是运行多个Web应用（一个Context代表一个Web应用），并负责安装、展开、启动和结束每个Web应用。

Host组件代表的虚拟主机，对应了服务器中一个网络名实体(如”wwwtestcom”，或IP地址”116252525”)；为了使用户可以通过网络名连接Tomcat服务器，这个名字应该在DNS服务器上注册。

客户端通常使用主机名来标识它们希望连接的服务器；该主机名也会包含在HTTP请求头中。Tomcat从HTTP头中提取出主机名，寻找名称匹配的主机。如果没有匹配，请求将发送至默认主机。因此默认主机不需要是在DNS服务器中注册的网络名，因为任何与所有Host名称不匹配的请求，都会路由至默认主机。

（3）Host的配置

在第一部分的例子中，Host的配置如下：

下面对其中配置的属性进行说明：

name属性指定虚拟主机的主机名，一个Engine中有且仅有一个Host组件的name属性与Engine组件的defaultHost属性相匹配；一般情况下，主机名需要是在DNS服务器中注册的网络名，但是Engine指定的defaultHost不需要，原因在前面已经说明。

unpackWARs指定了是否将代表Web应用的WAR文件解压；如果为true，通过解压后的文件结构运行该Web应用，如果为false，直接使用WAR文件运行Web应用。

Host的autoDeploy和appBase属性，与Host内Web应用的自动部署有关；此外，本例中没有出现的xmlBase和deployOnStartup属性，也与Web应用的自动部署有关；将在下一节(Context)中介绍。

6、Context

（1）Context的作用

Context元素代表在特定虚拟主机上运行的一个Web应用。在后文中，提到Context、应用或Web应用，它们指代的都是Web应用。每个Web应用基于WAR文件，或WAR文件解压后对应的目录（这里称为应用目录）。

Context是Host的子容器，每个Host中可以定义任意多的Context元素。

在第一部分的例子中，可以看到serverxml配置文件中并没有出现Context元素的配置。这是因为，Tomcat开启了自动部署，Web应用没有在serverxml中配置静态部署，而是由Tomcat通过特定的规则自动部署。下面介绍一下Tomcat自动部署Web应用的机制。

（2）Web应用自动部署

Host的配置

要开启Web应用的自动部署，需要配置所在的虚拟主机；配置的方式就是前面提到的Host元素的deployOnStartup和autoDeploy属性。如果deployOnStartup和autoDeploy设置为true，则tomcat启动自动部署：当检测到新的Web应用或Web应用的更新时，会触发应用的部署(或重新部署)。二者的主要区别在于，deployOnStartup为true时，Tomcat在启动时检查Web应用，且检测到的所有Web应用视作新应用；autoDeploy为true时，Tomcat在运行时定期检查新的Web应用或Web应用的更新。除此之外，二者的处理相似。

通过配置deployOnStartup和autoDeploy可以开启虚拟主机自动部署Web应用；实际上，自动部署依赖于检查是否有新的或更改过的Web应用，而Host元素的appBase和xmlBase设置了检查Web应用更新的目录。

其中，appBase属性指定Web应用所在的目录，默认值是webapps，这是一个相对路径，代表Tomcat根目录下webapps文件夹。

xmlBase属性指定Web应用的XML配置文件所在的目录，默认值为conf//，例如第一部分的例子中，主机localhost的xmlBase的默认值是$TOMCAT_HOME/conf/Catalina/localhost。

检查Web应用更新

一个Web应用可能包括以下文件：XML配置文件，WAR包，以及一个应用目录(该目录包含Web应用的文件结构)；其中XML配置文件位于xmlBase指定的目录，WAR包和应用目录位于appBase指定的目录。

Tomcat按照如下的顺序进行扫描，来检查应用更新：

A、扫描虚拟主机指定的xmlBase下的XML配置文件

B、扫描虚拟主机指定的appBase下的WAR文件

C、扫描虚拟主机指定的appBase下的应用目录

元素的配置

Context元素最重要的属性是docBase和path，此外reloadable属性也比较常用。

docBase指定了该Web应用使用的WAR包路径，或应用目录。需要注意的是，在自动部署场景下(配置文件位于xmlBase中)，docBase不在appBase目录中，才需要指定；如果docBase指定的WAR包或应用目录就在docBase中，则不需要指定，因为Tomcat会自动扫描appBase中的WAR包和应用目录，指定了反而会造成问题。

path指定了访问该Web应用的上下文路径，当请求到来时，Tomcat根据Web应用的 path属性与URI的匹配程度来选择Web应用处理相应请求。例如，Web应用app1的path属性是”/app1”，Web应用app2的path属性是”/app2”，那么请求/app1/indexhtml会交由app1来处理；而请求/app2/indexhtml会交由app2来处理。如果一个Context元素的path属性为””，那么这个Context是虚拟主机的默认Web应用；当请求的uri与所有的path都不匹配时，使用该默认Web应用来处理。

但是，需要注意的是，在自动部署场景下(配置文件位于xmlBase中)，不能指定path属性，path属性由配置文件的文件名、WAR文件的文件名或应用目录的名称自动推导出来。如扫描Web应用时，发现了xmlBase目录下的app1xml，或appBase目录下的app1WAR或app1应用目录，则该Web应用的path属性是”app1”。如果名称不是app1而是ROOT，则该Web应用是虚拟主机默认的Web应用，此时path属性推导为””。

reloadable属性指示tomcat是否在运行时监控在WEB-INF/classes和WEB-INF/lib目录下class文件的改动。如果值为true，那么当class文件改动时，会触发Web应用的重新加载。在开发环境下，reloadable设置为true便于调试；但是在生产环境中设置为true会给服务器带来性能压力，因此reloadable参数的默认值为false。

下面来看自动部署时，xmlBase下的XML配置文件app1xml的例子：

在该例子中，docBase位于Host的appBase目录之外；path属性没有指定，而是根据app1xml自动推导为”app1”；由于是在开发环境下，因此reloadable设置为true，便于开发调试。

自动部署举例

最典型的自动部署，就是当我们安装完Tomcat后，$TOMCAT_HOME/webapps目录下有如下文件夹：

当我们启动Tomcat后，可以使用http://localhost:8080/来访问Tomcat，其实访问的就是ROOT对应的Web应用；我们也可以通过http://localhost:8080/docs来访问docs应用，同理我们可以访问examples/host-manager/manager这几个Web应用。

（3）serverxml中静态部署Web应用

除了自动部署，我们也可以在serverxml中通过元素静态部署Web应用。静态部署与自动部署是可以共存的。在实际应用中，并不推荐使用静态部署，因为serverxml 是不可动态重加载的资源，服务器一旦启动了以后，要修改这个文件，就得重启服务器才能重新加载。而自动部署可以在Tomcat运行时通过定期的扫描来实现，不需要重启服务器。

serverxml中使用Context元素配置Web应用，Context元素应该位于Host元素中。举例如下：

1

docBase：静态部署时，docBase可以在appBase目录下，也可以不在；本例中，docBase不在appBase目录下。

path：静态部署时，可以显式指定path属性，但是仍然受到了严格的限制：只有当自动部署完全关闭(deployOnStartup和autoDeploy都为false)或docBase不在appBase中时，才可以设置path属性。在本例中，docBase不在appBase中，因此path属性可以设置。

reloadable属性的用法与自动部署时相同。

四、核心组件的关联

1、整体关系

核心组件之间的整体关系，在上一部分有所介绍，这里总结一下：

Server元素在最顶层，代表整个Tomcat容器；一个Server元素中可以有一个或多个Service元素。

Service在Connector和Engine外面包了一层，把它们组装在一起，对外提供服务。一个Service可以包含多个Connector，但是只能包含一个Engine；Connector接收请求，Engine处理请求。

Engine、Host和Context都是容器，且 Engine包含Host，Host包含Context。每个Host组件代表Engine中的一个虚拟主机；每个Context组件代表在特定Host上运行的一个Web应用。

2、如何确定请求由谁处理？

当请求被发送到Tomcat所在的主机时，如何确定最终哪个Web应用来处理该请求呢？

（1）根据协议和端口号选定Service和Engine

Service中的Connector组件可以接收特定端口的请求，因此，当Tomcat启动时，Service组件就会监听特定的端口。在第一部分的例子中，Catalina这个Service监听了8080端口（基于HTTP协议）和8009端口（基于AJP协议）。当请求进来时，Tomcat便可以根据协议和端口号选定处理请求的Service；Service一旦选定，Engine也就确定。

通过在Server中配置多个Service，可以实现通过不同的端口号来访问同一台机器上部署的不同应用。

（2）根据域名或IP地址选定Host

Service确定后，Tomcat在Service中寻找名称与域名/IP地址匹配的Host处理该请求。如果没有找到，则使用Engine中指定的defaultHost来处理该请求。在第一部分的例子中，由于只有一个Host（name属性为localhost），因此该Service/Engine的所有请求都交给该Host处理。

（3）根据URI选定Context/Web应用

这一点在Context一节有详细的说明：Tomcat根据应用的 path属性与URI的匹配程度来选择Web应用处理相应请求，这里不再赘述。

（4）举例

以请求http://localhost:8080/app1/indexhtml为例，首先通过协议和端口号（http和8080）选定Service；然后通过主机名（localhost）选定Host；然后通过uri（/app1/indexhtml）选定Web应用。

3、如何配置多个服务

通过在Server中配置多个Service服务，可以实现通过不同的端口号来访问同一台机器上部署的不同Web应用。

在serverxml中配置多服务的方法非常简单，分为以下几步：

（1）复制元素，放在当前后面。

（2）修改端口号：根据需要监听的端口号修改元素的port属性；必须确保该端口没有被其他进程占用，否则Tomcat启动时会报错，而无法通过该端口访问Web应用。

以Win7为例，可以用如下方法找出某个端口是否被其他进程占用：netstat -aon|findstr “8081″发现8081端口被PID为2064的进程占用，tasklist |findstr “2064″发现该进程为FrameworkServiceexe(这是McAfee杀毒软件的进程)。

（3）修改Service和Engine的name属性

（4）修改Host的appBase属性（如webapps2）

（5）Web应用仍然使用自动部署

（6）将要部署的Web应用(WAR包或应用目录)拷贝到新的appBase下。

以第一部分的serverxml为例，多个Service的配置如下：

http://localhost:8080/docs/

http://localhost:8084/docs/

五、其他组件

除核心组件外，serverxml中还可以配置很多其他组件。下面只介绍第一部分例子中出现的组件，如果要了解更多内容，可以查看Tomcat官方文档。

1、Listener

Listener(即监听器)定义的组件，可以在特定事件发生时执行特定的操作；被监听的事件通常是Tomcat的启动和停止。

监听器可以在Server、Engine、Host或Context中，本例中的监听器都是在Server中。实际上，本例中定义的6个监听器，都只能存在于Server组件中。监听器不允许内嵌其他组件。

监听器需要配置的最重要的属性是className，该属性规定了监听器的具体实现类，该类必须实现了orgapachecatalinaLifecycleListener接口。

下面依次介绍例子中配置的监听器：

VersionLoggerListener：当Tomcat启动时，该监听器记录Tomcat、Java和操作系统的信息。该监听器必须是配置的第一个监听器。

AprLifecycleListener：Tomcat启动时，检查APR库，如果存在则加载。APR，即Apache Portable Runtime，是Apache可移植运行库，可以实现高可扩展性、高性能，以及与本地服务器技术更好的集成。

JasperListener：在Web应用启动之前初始化Jasper，Jasper是JSP引擎，把JVM不认识的JSP文件解析成java文件，然后编译成class文件供JVM使用。

JreMemoryLeakPreventionListener：与类加载器导致的内存泄露有关。

GlobalResourcesLifecycleListener：通过该监听器，初始化< GlobalNamingResources>标签中定义的全局JNDI资源；如果没有该监听器，任何全局资源都不能使用。< GlobalNamingResources>将在后文介绍。

ThreadLocalLeakPreventionListener：当Web应用因thread-local导致的内存泄露而要停止时，该监听器会触发线程池中线程的更新。当线程执行完任务被收回线程池时，活跃线程会一个一个的更新。只有当Web应用(即Context元素)的renewThreadsWhenStoppingContext属性设置为true时，该监听器才有效。

2、GlobalNamingResources与Realm

第一部分的例子中，Engine组件下定义了Realm组件：

Realm，可以把它理解成“域”；Realm提供了一种用户密码与web应用的映射关系，从而达到角色安全管理的作用。在本例中，Realm的配置使用name为UserDatabase的资源实现。而该资源在Server元素中使用GlobalNamingResources配置：

GlobalNamingResources元素定义了全局资源，通过配置可以看出，该配置是通过读取$TOMCAT_HOME/ conf/tomcat-usersxml实现的。

关于Tomcat域管理的更多内容，可以参考：Realm域管理

3、Valve

在第一部分的例子中，Host元素内定义了Valve组件：

单词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：指定记录日志的格式，本例中各项的含义如下：

%h：远程主机名或IP地址；如果有nginx等反向代理服务器进行请求分发，该主机名/IP地址代表的是nginx，否则代表的是客户端。后面远程的含义与之类似，不再解释。

%l：远程逻辑用户名，一律是”-”，可以忽略。

%u：授权的远程用户名，如果没有，则是”-”。

%t：访问的时间。

%r：请求的第一行，即请求方法(get/post等)、uri、及协议。

%s：响应状态，200,404等等。

%b：响应的数据量，不包括请求头，如果为0，则是””-。

例如，下面是访问日志中的一条记录

pattern的配置中，除了上述各项，还有一个非常常用的选项是%D，含义是请求处理的时间(单位是毫秒)，对于统计分析请求的处理速度帮助很大。

开发人员可以充分利用访问日志，来分析问题、优化应用。例如，分析访问日志中各个接口被访问的比例，不仅可以为需求和运营人员提供数据支持，还可以使自己的优化有的放矢；分析访问日志中各个请求的响应状态码，可以知道服务器请求的成功率，并找出有问题的请求；分析访问日志中各个请求的响应时间，可以找出慢请求，并根据需要进行响应时间的优化。

502 Bad Gateway是指错误网关；无效网关；在互联网中表示一种网络错误。表现在WEB浏览器中给出的页面反馈。

常见的解决方法有如下两种：

1：php-cgi进程数不够用 （我就是采用此方法解决的）

vim php-fpmconf

修改其中的2个参数

（1）在安装好使用过程中出现502问题，一般是因为默认php-cgi进程是5个，可能因为phpcgi进程不够用而造成502，需要修改/usr/local/php/etc/php-fpmconf 将其中的max_children值适当增加

这个数值是不确定的 需要我们自己算的,这个值原则上是越大越好，php-cgi的进程多了就会处理的很快，排队的请求就会很少，减小出现502错误的机率。

一般来说，一台服务器的正常情况下每一个php-cgi要耗费的内存为20M左右。如果我就将此值设为80，那么也就是说大概要耗费服务器1600M内存。

查看一下当前系统中有多少个php-cgi进程在运行

netstat -anpo | grep php-cgi | wc -l

如果这个值接近你的在配置文件里面设置的值，说明需要增加

注：这要根据机器的实际情况而定，每个机器的硬件设施和环境不一样

参数为：<value name=”max_children”>80</value>

（2）另外一个参数就是php-cgi脚本的执行时间

<value name=”request_terminate_timeout”>0s</value>这里写0s的意思是让php-cgi一直执行下去，没有时间限制。

注意：如果你做不到这一点，也就 是说你的PHP-CGI可能出现某个BUG，或者你的宽带不够充足或者其他的原因导致你的PHP-CGI假死那么就建议你给 request_terminate_timeout赋一个值，这个值可以根据服务器的性能进行设定。一般来说性能越好你可以设置越高，20分钟-30分 钟都可以。

修改完这两个参数，重启一下php-cgi，看是否还出现502错误

2： php执行时间长

php执行超时，修改/usr/local/php/etc/phpini 将max_execution_time 改为300

重启一下php-cgi，看是否还出现502错误

3： php-cgi进程死掉

杀死其进程，重启php-cgi

如果nginx和tomcat在同一台服务器可以代理，则说明nginx的犯下那个代理功能是正常的。

但是放在两台服务器则失效，需要考虑的是：A服务器是否有权限访问B服务器。

如果B服务的地址为：19216810010:8080，A的配置为：

if ($request_uri ~ "xxx") {

proxy_pass http://19216810010:8080;

break;

}

对于一条请求，先看一下A转发的请求是否到达了B服务器，如果到达B了然后再看下具体什么原因没有跳转。

如果这条请求根本就没有到达B服务器，可以把nginx的日志级别调成debug，然后跟踪nginx的错误日志看下具体原因。

不同的代理使用不同的端口。有时，当我们设置代理时，无法连接，也可能是由于端口设置错误。与IPIDEA全球HTTP去了解下代理服务器通常用哪些端口，使用代理服务器怎么设置的呢？

一、代理服务器通常用哪些端口

1SOCKS代理，常用端口号：1080、tomcat8080、weblogic7001。

2HTTP代理，常用端口号：80/8080/3128/8081/9080；能够代理客户机的HTTP访问，主要是代理浏览器访问网页。

3Telnet（远程登录）协议代理，常用端口：23。

4FTP代理，常用端口号:21；可以代理客户机上的FTP软件访问FTP服务器。

二、默认使用的代理端口有哪些

许多socks代理服务器程序使用1080作为默认端口。这么多socks代理正在使用端口1080但是有许多代理服务器程序使用不同的默认端口。例如，许多代理服务器程序使用8080作为默认端口。

代理管理员选择这些端口有一些原因。80/443端口是HTTP/HTTPSWeb服务器的默认端口。公司不会阻止这些端口。8080是HTTP备用端口，通常用于Web代理和缓存服务器。

三、使用代理服务器怎么设置

使用IP与端口设置，这里以浏览器为例子，介绍个设置的方法，首先确定下代理服务器方便提取IP比如IPIDEA，并记录IP地址与端口。

其次，打开浏览器，找个设置，高级设置，并找到其中的网络。选择修改代理服务器设置，打开之后会看到当前选择的是连接选项，并在下方找到局域网设置，弹出“局域网(LAN)设置”窗口。在为LAN使用代理服务器前的复选框打钩，去网上搜索常用的代理服务器，在地址中填入ip地址，端口中填入代理服务器的端口，最后单击“确定”即可。