Tomcat，

Java体系结构包括四个独立但相关的技术：

Java程序设计语言

Java class文件格式

Java API

Java VM

用Java语言编译源代码，把它编译成Java Class文件，然后在Java VM中运行class文件；当编写程序时，通过调用类(Java API)中的方法来访问系统资源，而当程序运行时，它通过调用class文件中实现了Java API的方法也满足程序的Java API调用。Java VM和Java API一起组成了一个“平台”，所有Java程序都在其上编译和运行，因此，它们有时也被称作Java运行时环境。

Java VM的主要任务是装载class文件并且执行其中的字节码。Java VM包含一个类装载器(class loader)，它可以从程序和API装载class文件；而Java API的类只在程序执行中需要时才会被装载。

Java字节码由执行引擎来执行。而不同的Java VM中，其执行引擎的实现可能各不相同。最简单的执行引擎不是一次性解释字节码，而另一种称为“即时编译器(just-in-time compiler)”的执行引擎执行速度更快，但要消耗更多的内存资源。即时编译模式下，第一次被执行的字节码会被编译成本地机器代码并缓存下来以实现“复用”。第三种执行引擎是所谓的自适应优化器，此种方法中，虚拟机始的时候解释字节码，介是会监视运行中程序的活动，并且记录下使用最频繁的代码。程序运行时，虚拟机只把那些活动最频繁的代码编译成本地代码，而不频繁的代码则仍然保留为字节码由虚拟机解释执行。自适应优化器可以使得Java VM在80%-90%的时间里执行被优化过的本地代码，而只需要编译10%-20%对性能有影响的代码。最后一种虚拟机由硬件芯片构成，它用本地方法执行Java字节码，其执行引擎内嵌于芯片中。

Sun公司创建了第一个Servlet容器，即Java Web Server， 但JWS只是为了演示Servlet的相应功能，所以其很不稳定。与此同时，ASF创建了JServ项目，一个能够与apache整合起来的servlet容器。1999年，Sun把JWS捐给了ASF，于是两个项目合二为一，即今天Tomcat的前身。第一个tomcat版本是Tomcat 3.x系列，而发布于2001年Tomcat4.0则是在此前基础上进行了重新设计和实现，其代码项目被命名为Catalina。目前最新的版本则是7.x系列。

Java SE则包含了Java二进制程序(如JVM和Java字节码编译器)和Java的核心代码库，而Jave EE标准则包含了一组适用于创建企业级Web应用程序的API。Jave EE建立在Java SE的基础上，并依赖于Java SE才能正常工作。当然，任何级别的应用程序均能从Java EE中获益，但Jave EE却更适合解决大型软件系统设计中的问题。

JAVA EE包含多个独立的API，Servlet和JSP就是其中的两个，而JAVA EE中著名的API中还包含如下的几个：

JAVA EE APIs:
EJB(Enterprise JavaBeans)：JAVA相关的诸多高级功能的实现，如RMI（Remote Method Invocation), 对象/关系映射，跨越多个数据源的分布式事务等；

JMS(Java Message Service)：高性能异步消息服务，实现JAVA EE应用程序与非JAVA程序的“透明”通信；

JMX（Java Management Extensions）：在程序运行时对其进行交互式监控和管理的机制；

JTA（Java Transaction API）：允许应用程序在自身的一个或多个组件中平滑地处理错误的机制；

JavaMail：通过工业标准的POP/SMTP/IMAP协议发送和接收邮件的机制；

Java SE APIs：
JNDI（Java Naming and Directory Interface）:用于与LDAP服务交互的API；
JAXP（Java API for XML Processing）:用于分析及转换XML（基于XSLT实现）；

Java SE API + JDK

JAVA EE Application Servers:
Websphere
Weblogic
oc4j
JBoss
JOnAS
Geronimo
Glassfish

risen

Sun –> TWS
RI: Reference Implimentation
参考实现

ASF：Apache Software Foundation
Jserv

Sun –> ASF
catalina
O’Reilly: Tomcat
男猫

类，.jar
JVM,

Tomcat: Servlet and JSP APIs, JNDI and JMX APIs.

Tomcat不是一个完整意义上的Jave EE服务器，它甚至都没有提供对哪怕是一个主要Java EE API的实现；但由于遵守apache开源协议，tomcat却又为众多的java应用程序服务器嵌入自己的产品中构建商业的java应用程序服务器，如JBoss和JOnAS。

尽管Tomcat对Jave EE API的实现并不完整，然而很企业也在渐渐抛弃使用传统的Java EE技术（如EJB）转而采用一些开源组件来构建复杂的应用。这些开源组件如Structs、Spring和Hibernate，而Tomcat能够对这些组件实现完美的支持。

HTTP是一种无状态的协议，在用户的一次连接请求响应完成后，服务器端将无法识别在后续的连接请求中再次识别此用户，交将其所有请求关联起来。为了解决这个问题，java container通过一个临时的cookie来为此用户保存一个标识，此标识即所谓的用户session。

在第一次调用之后，JSP会被编译成一个servlet类，在后续的操作中则可以直接使用此类，从而避免了对每一次调用的都要重新分析和编译。因此，类似servlet，JSP的执行需要在container中完成。JSP的container跟servlet的container基本相同，但在JSP执行之前，需要一些额外的步骤如与servlet代码建立会话等。Tomcat包含了一个叫做Catalina的Servlet container（执行servlet和编译过的JSP）和一个JSP编译器（Jasper编译器）。事实上，一个包含了JSP编译器和Servlet容器的应用程序组合通过被称作Web容器。

JSP和Servlet的最大区别在于，Servlet通常需要事先编译好，而JSP则并非必须事先编译。这意味着Servlet通常放置于私有资源区域，而JSP则通常以嵌入代码的方式包含于HTML页面文件中，这些HTML文件通常放置在公开资源区域。

MVC架构：

Controller，Model和View各自独立，一个流行的开源实现是Apache Structs框架；目今，设计优良的Web应用程序通常用相就的技术实现相应的功能，比如：
1、Servlet用于实现应用逻辑；
2、JSP用于内容展示；
3、标签库和JSP扩展语言用于替换在JSP内部嵌入Java代码，进而降低了HTML维护的复杂度；
4、MVC框架用于实现展示和应用逻辑的分离；

对于一个Web应用程序而言，其通常由Servlets、JSP和其它文件等共同组成。这些文件通常被打包成WAR（Web Application Archive）格式，并以.war作为打包后的文件扩展名。而Servlet规范则定义了在WAR内部组织这些文件的标准目录结构。其目录和功用如下：
/ Web应用程序的根目录，所有可被公开访问的文件均放置于此处，如HTML、JSP和图片文件等；
/WEB-INF 此目录为私有资源目录，其内部的所有文件和子目录均不能被公开访问；包含着此Web应用程序的配置文件web.xml（程序结构描述符文件）通常放置于此目录；
/WEB-INF/classes 当前Web应用程序的类文件的存在目录；
/WEB-INF/lib 可被打包为JAR格式的类文件通常放置于此目录；

安装tomcat：

一、先安装JVM

二、安装配置tomcat

A Tomcat init script for Linux

#!/bin/sh
# Tomcat init script for Linux.
#
# chkconfig: 2345 96 14
# description: The Apache Tomcat servlet/JSP container.
JAVA_HOME=/usr/java/jdk1.7.0_05
CATALINA_HOME=/opt/apache-tomcat-7.0.29
export JAVA_HOME CATALINA_HOME
exec $CATALINA_HOME/bin/catalina.sh $*

Tomcat的架构：

Tomcat 6支持Servlet 2.5和JSP 2.1的规范，它由一组嵌套的层次和组件组成，一般可分为以下四类：
顶级组件：位于配置层次的顶级，并且彼此间有着严格的对应关系；
连接器：连接客户端（可以是浏览器或Web服务器）请求至Servlet容器，
容器：包含一组其它组件；
被嵌套的组件：位于一个容器当中，但不能包含其它组件；

各常见组件：

1、服务器(server)：Tomcat的一个实例，通常一个JVM只能包含一个Tomcat实例；因此，一台物理服务器上可以在启动多个JVM的情况下在每一个JVM中启动一个Tomcat实例，每个实例分属于一个独立的管理端口。这是一个顶级组件。
2、服务(service)：一个服务组件通常包含一个引擎和与此引擎相关联的一个或多个连接器。给服务命名可以方便管理员在日志文件中识别不同服务产生的日志。一个server可以包含多个service组件，但通常情下只为一个service指派一个server。

连接器类组件：

3、连接器(connectors)：负责连接客户端（可以是浏览器或Web服务器）请求至Servlet容器内的Web应用程序，通常指的是接收客户发来请求的位置及服务器端分配的端口。默认端口通常是HTTP协议的8080，管理员也可以根据自己的需要改变此端口。一个引擎可以配置多个连接器，但这些连接器必须使用不同的端口。默认的连接器是基于HTTP/1.1的Coyote。同时，Tomcat也支持AJP、JServ和JK2连接器。

容器类组件：

4、引擎(Engine)：引擎通是指处理请求的Servlet引擎组件，即Catalina Servlet引擎，它检查每一个请求的HTTP首部信息以辨别此请求应该发往哪个host或context，并将请求处理后的结果返回的相应的客户端。严格意义上来说，容器不必非得通过引擎来实现，它也可以是只是一个容器。如果Tomcat被配置成为独立服务器，默认引擎就是已经定义好的引擎。而如果Tomcat被配置为Apache Web服务器的提供Servlet功能的后端，默认引擎将被忽略，因为Web服务器自身就能确定将用户请求发往何处。一个引擎可以包含多个host组件。
5、主机(Host)：主机组件类似于Apache中的虚拟主机，但在Tomcat中只支持基于FQDN的“虚拟主机”。一个引擎至少要包含一个主机组件。
6、上下文(Context)：Context组件是最内层次的组件，它表示Web应用程序本身。配置一个Context最主要的是指定Web应用程序的根目录，以便Servlet容器能够将用户请求发往正确的位置。Context组件也可包含自定义的错误页，以实现在用户访问发生错误时提供友好的提示信息。

被嵌套类(nested)组件：

这类组件通常包含于容器类组件中以提供具有管理功能的服务，它们不能包含其它组件，但有些却可以由不同层次的容器各自配置。
7、阀门(Valve)：用来拦截请求并在将其转至目标之前进行某种处理操作，类似于Servlet规范中定义的过滤器。Valve可以定义在任何容器类的组件中。Valve常被用来记录客户端请求、客户端IP地址和服务器等信息，这种处理技术通常被称作请求转储(request dumping)。请求转储valve记录请求客户端请求数据包中的HTTP首部信息和cookie信息文件中，响应转储valve则记录响应数据包首部信息和cookie信息至文件中。
8、日志记录器(Logger)：用于记录组件内部的状态信息，可被用于除Context之外的任何容器中。日志记录的功能可被继承，因此，一个引擎级别的Logger将会记录引擎内部所有组件相关的信息，除非某内部组件定义了自己的Logger组件。
9、领域(Realm)：用于用户的认证和授权；在配置一个应用程序时，管理员可以为每个资源或资源组定义角色及权限，而这些访问控制功能的生效需要通过Realm来实现。Realm的认证可以基于文本文件、数据库表、LDAP服务等来实现。Realm的效用会遍及整个引擎或顶级容器，因此，一个容器内的所有应用程序将共享用户资源。同时，Realm可以被其所在组件的子组件继承，也可以被子组件中定义的Realm所覆盖。

引擎(Engine)

引擎是指处理请求的Servlet引擎组件，即Catalina Servlet引擎，它从HTTPconnector接收请求并响应请求。它检查每一个请求的HTTP首部信息以辨别此请求应该发往哪个host或context，并将请求处理后的结果返回的相应的客户端。严格意义上来说，容器不必非得通过引擎来实现，它也可以是只是一个容器。如果Tomcat被配置成为独立服务器，默认引擎就是已经定义好的引擎。而如果Tomcat被配置为Apache Web服务器的提供Servlet功能的后端，默认引擎将被忽略，因为Web服务器自身就能确定将用户请求发往何处。一个引擎可以包含多个host组件。

Tomcat连接器架构：

基于Apache做为Tomcat前端的架构来讲，Apache通过mod_jk、mod_jk2或mod_proxy模块与后端的Tomcat进行数据交换。而对Tomcat来说，每个Web容器实例都有一个Java语言开发的连接器模块组件，在Tomcat6中，这个连接器是org.apache.catalina.Connector类。这个类的构造器可以构造两种类别的连接器：HTTP/1.1负责响应基于HTTP/HTTPS协议的请求，AJP/1.3负责响应基于AJP的请求。但可以简单地通过在server.xml配置文件中实现连接器的创建，但创建时所使用的类根据系统是支持APR(Apache Portable Runtime)而有所不同。
APR是附加在提供了通用和标准API的操作系统之上一个通讯层的本地库的集合，它能够为使用了APR的应用程序在与Apache通信时提供较好伸缩能力时带去平衡效用。
同时，需要说明的是，mod_jk2模块目前已经不再被支持了，mod_jk模块目前还apache被支持，但其项目活跃度已经大大降低。因此，目前更常用 的方式是使用mod_proxy模块。

如果支持APR：
1、HTTP/1.1：org.apache.cotote.http11.Http11AprProtocol
2、AJP/1.3：org.apache.coyote.ajp.AjpAprProtocol
如果不支持APR：
HTTP/1.1: org.apache.coyote.http11.Http11Protocol
AJP/1.3: org.apache.jk.server.JkCoyoteHandler

连接器协议：

Tomcat的Web服务器连接器支持两种协议：AJP和HTTP，它们均定义了以二进制格式在Web服务器和Tomcat之间进行数据传输，并提供相应的控制命令。

AJP(Apache JServ Protocol)协议：
目前正在使用的AJP协议的版本是通过JK和JK2连接器提供支持的AJP13，它基于二进制的格式在Web服务器和Tomcat之间传输数据，而此前的版本AJP10和AJP11则使用文本格式传输数据。

HTTP协议：诚如其名称所表示，其是使用HTTP或HTTPS协议在Web服务器和Tomcat之间建立通信，此时，Tomcat就是一个完全功能的HTTP服务器，它需要监听在某端口上以接收来自于商前服务器的请求。

Tomcat的配置文件：

Tomcat的配置文件默认存放在$CATALINA_HOME/conf目录中，主要有以下几个：
server.xml: Tomcat的主配置文件，包含Service, Connector, Engine, Realm, Valve, Hosts主组件的相关配置信息；
web.xml：遵循Servlet规范标准的配置文件，用于配置servlet，并为所有的Web应用程序提供包括MIME映射等默认配置信息；
tomcat-user.xml：Realm认证时用到的相关角色、用户和密码等信息；Tomcat自带的manager默认情况下会用到此文件；在Tomcat中添加/删除用户，为用户指定角色等将通过编辑此文件实现；
catalina.policy：Java相关的安全策略配置文件，在系统资源级别上提供访问控制的能力；
catalina.properties：Tomcat内部package的定义及访问相关的控制，也包括对通过类装载器装载的内容的控制；Tomcat6在启动时会事先读取此文件的相关设置；
logging.properties: Tomcat6通过自己内部实现的JAVA日志记录器来记录操作相关的日志，此文件即为日志记录器相关的配置信息，可以用来定义日志记录的组件级别以及日志文件的存在位置等；
context.xml：所有host的默认配置信息；

一、server.xml

Tomcat以面向对象的方式运行，它可以在运行时动态加载配置文件中定义的对象结构，这有点类似于apache的httpd模块的调用方式。server.xml中定义的每个主元素都会被创建为对象，并以某特定的层次结构将这些对象组织在一起。下面是个样样例配置：

!/bin/sh

Tomcat init script for Linux.

#

chkconfig: 2345 96 14

description: The Apache Tomcat servlet/JSP container.

JAVA_OPTS=’-Xms64m -Xmx128m’
JAVA_HOME=/usr/java/jdk1.7.0_05
CATALINA_HOME=/usr/local/apache-tomcat-7.0.29
export JAVA_HOME CATALINA_HOME
exec CATALINAHOME/bin/catalina.sh$CATALIN{A}_{H}OME/bin/catalina.sh$*

APR即Apache Portable Runtime，原来是apache2的一个库，后来被独立成了一个项目。基于此库文件，Tomcat可以表现出更好的稳定性和性能，尤其是Tomcat作为apache的后端Servlet容器时。

事先安装apr-devel包，而后编译安装tomcat的APR JNI。安装方法如下：

cd $CATALINA_HOME/bin

tar xf tomcat-native.tar.gz

cd tomcat-native-1.1.22-src/jni/native/

./configure –with-apr=/usr –with-ssl –with-apxs

make && make install

echo “/usr/local/apr/lib/” > /etc/ld.so.conf.d/apr.conf

ldconfig

应用程序：
jforum
java center home

配置tomcat启用Manager

Manager的四个管理角色：
manager-gui - allows access to the HTML GUI and the status pages
manager-script - allows access to the text interface and the status pages
manager-jmx - allows access to the JMX proxy and the status pages
manager-status - allows access to the status pages only

添加一个新的Host:
编辑server.xml:

httpd -D DUMP_MODULES

……………………
proxy_module (shared)
proxy_balancer_module (shared)
proxy_ftp_module (shared)
proxy_http_module (shared)
proxy_connect_module (shared)
……………………

2、在httpd.conf的全局配置段或虚拟主机中添加如下内容：
ProxyVia On
ProxyRequests Off
ProxyPreserveHost On

./configure –prefix=/usr/local/apache –enable-proxy –enable-proxy-http –enable-proxy-ajp

2、配置apache加载相应的模块：
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so

3、配置apache代理tomcat：

第一种方法，基于proxy-http：
ProxyPass /my-webapp http://www.magedu.com:8080/my-webapp
ProxyPassReverse /my-webapp http://www.magedu.com:8080/my-webapp
ProxyVia On

第二种方法，基于proxy-ajp：
ProxyPass /my-webapp ajp://tomcathost:8009/my-webapp
ProxyPassReverse /my-webapp ajp://tomcathost:8009/my-webapp
ProxyVia On

4、确保tomcat配置有如上使用的连接器；

tar xf httpd-2.4.2
cd httpd-2.4.2
./configure –prefix=/usr/local/apache –sysconfdir=/etc/httpd –enable-so –enable-ssl –enable-cgi –enable-rewrite –with-zlib –with-pcre –with-apr=/usr/local/apr –with-apr-util=/usr/local/apr-util –enable-proxy –enable-proxy-http –enable-proxy-ajp
make && make install

tar xf tomcat-connectors-1.2.37-src.tar.gz
cd tomcat-connectors-1.2.37-src/native/
./configure –with-apxs=/usr/local/apache/bin/apxs
make && make install

server端session：
1、service向用户浏览器发送cookie，此cookie包含获取服务端session的标识。
2、向用户通过浏览器请求同一站点的页面时，相应的cookie信息会随之发送。
3、server从cookie信息中识别出与此浏览器相关的session标识，从而判别出当前server上此浏览器的session信息。

在用户浏览器不支持cookie的场景中，也可以基于URL重写实现session功能。简单来讲就是server端通过为任何一个响应给用户的URL附加上session id的方式来标识用户请求。

不过需要注意的是，每个浏览器进程都会各自管理各自跟服务端的会话ID，因此，在服务器端看来，同一个客户端上的多个浏览器进程会被识别成不同的客户端。

2012年7月7号：
Tomcat7的配置文件(conf目录中)：
catalina.policy: Tomcat7的安全策略，用于JVM强制将安全策略施加于Webapp；
catalina.properties: Tomcat启动时会扫描此文件，它包括共享的server、shared loader及JAR等；
server.xml: 主配置文件之一，包含了诸多的重要配置，如IP地址、端口、虚拟主机、context路径等；
tomcat-users.xml: 基于角色实现的认证及授权相关的文件；
logging.properties: Tomcat实例的日志相关的定义；
web.xml：定义tomcat实例启动时为所有装载至当前实例中的webapp定义的默认属性值；当然，某webapp也可以定义自己的属性来替代这里的默认值；
context.xml:

JDBC: (Java Database Connectivity) 基于java的数据库访问接口, 即用于让客户端访问数据库的API；
JNDI：(Java Naming and Directory Interface), JAVA的API之一，用于向java语言编写的应用程序提供命名及目录的功能；
DataSource: 用于通过JDBC API连接关系型数据库的Java对象，通常需要整合进JNDI并将数据源对象注册为一个JNDI的名称服务；这样对象可以被程序自身访问，并用于连接至数据库；一般说来，tomcat7连接至任何数据时通常需要提供以下几个参数：
IP地址
端口号
JNDI名称
数据库用户名及其密码
DBCP：(Dababase Connection Pool), 其通常位于TOMCAT_HOME或CATALINA_HOME/lib/tomcat-dbcp.jar中，用于实现连接池；

Tomcat Manager：
tomcat强大的管理工具，具有以下特性：
远程deploy新应用程序
清理空闲会话
在不重启container的情况下Undeploy应用程序
分析内存泄漏
JVM状态
服务器状态

然而，在tomcat7中，TM默认是禁用的。要启用之，需要编辑tomcat-users.xml文件；

Context:
对于应用程序来说，context路径是一个关键属性，其也经常用于虚拟主机的配置及.war文件中的URL映射。使用context可以降低系统负载，因为，当某URL请求到达tomcat时，如果没有context，tomcat需要搜索server.xml或context.xml的配置以确定此URL，否则则需要搜索所有的war文件来查找用户的请求的资源。

此外，context也可以让管理员基于每个app提供日志、appBase、DB连接等配置，这极大地增强配置的灵活性；

应用程序目录的结构：
/WEB-INF/web.xml：包含当前webapp的deploy描述符，如所有的servlets和JSP等动态文件的详细信息，会话超时时间和数据源等；因此，其也通常用于定义当前webapp特有的资源；
/WEB-INF/classes: 包含所有服务器端类及当前应用程序相关的其它第三方类等；
/WEB-INF/lib: 包含JSP所用到的JAR文件；

用于tomcat的webapp即可以多个独立的文件组成，也可以是jar打包后的单个文件；这些打包后的文件的扩展名可用于判断其内容的类型，如：
EJB通常打包为.jar
webapp通常打包为.war
资源适配器(Resource adapters)通常打包为.rar
企业级应用程序通常打包为.ear，它通常是整合的EJB、webapp及资源适配器文件；
Web服务通常会打包为.ear或.war；

于是，到底应该使用展开格式的文件还是打包为单个文件的格式，就需要根据需要进行了。一般说来，如果满足以下场景，就应该使用展开后的格式，而非打包格式：
1、需要在将来的某个时候更新应用程序中的部分内容；使用展开的格式可以避免重新deploy应用程序；
2、期望使用Tomcat Manager来动态编辑及选择deployment descriptor值；
3、应用程序中包含静态文件，而这些静态文件需要定期更新；

Deploy应用程序所涉及到的操作：
Deploy: 向tomcat实例提供某应用程序源文件，并让服务器将类加载进类加器中；这样，应用程序才可以为用户所使用；
Redeploy:用于更新deployment后的某应用程序或应用程序的部分内容；当redeploy整个应用程序时，当前应用程序的所有模块都必须要redeploy成功，否则整个webapp将会停止 ；
Stop: 卸载当前应用程序的所有类，并停止向用户提供服务；不过，其仍然会保留所有已deploy的文件及名称，并可用于后续的redeployment或starting；
Start: 重新装载当前应用的类至类加载器，并开启服务；
Undeploy: 停止某已经deploy的应用程序，并移除deploy产生的文件和名称；

Tomcat7 deploy应用程序的方法：
War格式的应用程序：将应用程序war文件放置于CATALINA_BASE目录中并重新启动tomcat；
没打包的应用程序：将应用程序的非归档文件旋转于CATALINA_BASE目录中；
Tomcat Manager：登录TM而后进行deploy；

telnet webserver

GET / HTTP/1.1
HOST:localhost
Connection:{Keep-Alive|Close}

<%@ page language=”java” %>
<%@ page import=”java.util.*” %>


JSP test page.


<% out.println(“Hello,world!”); %>

mkdir /usr/local/tcinstance2

cd /usr/local/tcinstance2

cp -a $CATALINA_HOME/conf .

mkdir common logs temp server shared webapps work

server.xml:

set CATALINA_BASE=”/usr/local/tcinstance2”

set CATALINA_HOME=”/usr/local/tomcat”

export CATALINA_BASE CATALINA_HOME

service tomcat start # Standard way to start on Linux

http://172.16.100.1/manager/html:
http://172.16.100.1/manager/text
http://172.16.100.1/manager/status

会话管理：
标准会话管理器和持久会话管理器

标准会话管理器(StandardManager)：

/usr/local/apache/bin/httpd -D DUMP_MODULES | grep proxy

proxy_module (shared)
proxy_connect_module (shared)
proxy_ftp_module (shared)
proxy_http_module (shared)
proxy_fcgi_module (shared)
proxy_scgi_module (shared)
proxy_ajp_module (shared)
proxy_balancer_module (shared)
proxy_express_module (shared)

2、在httpd.conf的全局配置段或虚拟主机中添加如下内容：
ProxyVia Off
ProxyRequests Off
ProxyPreserveHost Off

Load the mod_jk

LoadModule jk_module modules/mod_jk.so
JkWorkersFile /etc/httpd/extra/workers.properties
JkLogFile logs/mod_jk.log
JkLogLevel debug
JkMount /* TomcatA
JkMount /status/ stat1

除了需要使用LoadModule指令在apache中装载模块外，mod_jk还需要在apache的主配置文件中设置其它一些指令来配置其工作属性。如JkWorkersFile则用于指定保存了worker相关工作属性定义的配置文件，JkLogFile则用于指定mod_jk模块的日志文件，JkLogLevel则可用于指定日志的级别（info, error, debug），此外还可以使用JkRequestLogFormat自定义日志信息格式。而JkMount（格式： JkMount ）指定则用于控制URL与Tomcat workers的对应关系。

为了让apache能使用/etc/httpd/extra/httpd-jk.conf配置文件中的配置信息，需要编辑/etc/httpd/httpd.conf，添加如下一行：
Include /etc/httpd/extra/httpd-jk.conf

对于apache代理来说，每一个后端的Tomcat实例中的engine都可以视作一个worker，而每一个worker的地址、连接器的端口等信息都需要在apache端指定以便apache可以识别并使用这些worker。约定俗成，配置这些信息的文件通常为workers.properties，其具体路径则是使用前面介绍过的JkWorkersFile指定的，在apache启动时，mod_jk会扫描此文件获取每一个worker的配置信息。比如，我们这里使用/etc/httpd/extra/workers.properties。

workers.properties文件一般由两类指令组成：一是mod_jk可以连接的各worker名称列表，二是每一个worker的属性配置信息。它们分别遵循如下使用语法。

worker.list = < a comma separated list of worker names >
worker. . =

其中worker.list指令可以重复指定多次，而worker name则是Tomcat中engine组件jvmRoute参数的值。如：
worker.TomcatA.host=172.16.100.1

根据其工作机制的不同，worker有多种不同的类型，这是需要为每个worker定义的一项属性woker..type。常见的类型如下：
◇ ajp13：此类型表示当前worker为一个运行着的Tomcat实例。
◇ lb：lb即load balancing，专用于负载均衡场景中的woker；此worker并不真正负责处理用户请求，而是将用户请求调度给其它类型为ajp13的worker。
◇ status：用户显示分布式环境中各实际worker工作状态的特殊worker，它不处理任何请求，也不关联到任何实际工作的worker实例。具体示例如请参见后文中的配置。

worker其它常见的属性说明：
◇ host：Tomcat 7的worker实例所在的主机；
◇ port：Tomcat 7实例上AJP1.3连接器的端口；
◇ connection_pool_minsize：最少要保存在连接池中的连接的个数；默认为pool_size/2；
◇ connection_pool_timeout：连接池中连接的超时时长；
◇ mount：由当前worker提供的context路径，如果有多个则使用空格格开；此属性可以由JkMount指令替代；
◇ retries：错误发生时的重试次数；
◇ socket_timeout：mod_jk等待worker响应的时长，默认为0，即无限等待；
◇ socket_keepalive：是否启用keep alive的功能，1表示启用，0表示禁用；
◇ lbfactor：worker的权重，可以在负载均衡的应用场景中为worker定义此属性；

另外，在负载均衡模式中，专用的属性还有：
◇balance_workers：用于负载均衡模式中的各worker的名称列表，需要注意的是，出现在此处的worker名称一定不能在任何worker.list属性列表中定义过，并且worker.list属性中定义的worker名字必须包含负载均衡worker。具体示例请参见后文中的定义。
◇ method：可以设定为R、T或B；默认为R，即根据请求的个数进行调度；T表示根据已经发送给worker的实际流量大小进行调度；B表示根据实际负载情况进行调度。
◇sticky_session：在将某请求调度至某worker后，源于此址的所有后续请求都将直接调度至此worker，实现将用户session与某worker绑定。默认为值为1，即启用此功能。如果后端的各worker之间支持session复制，则可以将此属性值设为0。

根据前文中的指定，这里使用/etc/httpd/extra/workers.properties来定义一个名为TomcatA的worker，并为其指定几个属性。文件内容如下：
worker.list=TomcatA,stat1
worker.TomcatA.port=8009
worker.TomcatA.host=172.16.100.1
worker.TomcatA.type=ajp13
worker.TomcatA.lbfactor=1
worker.stat1.type = status

至此，一个基于mod_jk模块与后端名为TomcatA的worker通信的配置已经完成，重启httpd服务即可生效。

配置基于mod_jk的负载均衡

1、 为了避免用户直接访问后端Tomcat实例，影响负载均衡的效果，建议在Tomcat 7的各实例上禁用HTTP/1.1连接器。
2、为每一个Tomcat 7实例的引擎添加jvmRoute参数，并通过其为当前引擎设置全局惟一标识符。如下所示。需要注意的是，每一个实例的jvmRoute的值均不能相同。