Session sharing solution under the Apache+tomcat cluster deployment

Under multiple server cluster deployments, the traditional way to write session flags after logging in will not satisfy the exact judgment that the current user is not logged in after the request is positioned to another server because the current server does not save the user's session logon information. To solve this problem can be used in two ways: 1, session sharing, multiple server session copy save, a downtime will not affect the user's login status; 2, request accurate centralized positioning, that is, the current user's requests are centrally located in a server, Such a single server saved the user's session logon information, if downtime, it is equivalent to a single point of deployment, will be lost;

Apache provides a different configuration item for both of these methods:

Session Replication: Conversation replication, that is, the above method one;

Session Sticky: Sessions do not replicate, that is, the above method two;

is how to achieve it.

We know that the judgment of the session is achieved through a SessionID, the SessionID is stored in the cookie of the client, and each request is automatically shipped with the SessionID appended to the request.

As a parameter, and the above session control policy is configured, the SessionID is automatically extended to keep up with specific routing addresses, such as

jsessionid=ac7ef1caa8c6b0feb68e77d7d375e2af.b

The following. b is the name of the routing item configured in Apache, and the configuration of Apache can be found in the following articles:

Transfer from Network

Select Apache HTTP Server as the front-end load server, the backend selected two Tomcat as a cluster, this choice of configuration is session Sticky (sticky session),

This method forwards the same user's request to a specific Tomcat server, avoiding the replication of session in the cluster, the disadvantage is that the user only with one server communication, if the server down, then waste.
Using the model for mod_proxy_ajp.so, the entire configuration in Tomcat configuration file have relevant comments, just make the appropriate changes on the OK.
We selected the Apache HTTP server2.2.4,tomcat5.5.16.
First installs Apache HTTP Server, then modifies its configuration file http.conf, first load three model, the code is as follows: LoadModule Proxy_module modules/mod_proxy.so
LoadModule Proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule Proxy_balancer_module modules/mod_proxy_balancer.so then add the following code to the end of this profile:
Proxypass/balancer://tomcatcluster/lbmethod=byrequests Stickysession=jsessionid nofailover=Off timeout=5 Maxattempts=3
proxypassreverse/balancer://tomcatcluster/

<proxy balancer://tomcatcluster>
Balancermember ajp://localhost:8009 Route=a
Balancermember ajp://localhost:9009 route=b
</Proxy>
The above code configures the parameters of Proxy,<proxy> module defines a balanced load configuration, where two Tomcat servers are configured on the same server with ports 8009, 9009,

and configure the respective route so that Apache server can forward requests to specific Tomcat according to route.
Next, modify Tomcat's Server.xml file as follows:

<!--Define a AJP 1.3 Connector on port 8009-->
<connector port= "8009"
Enablelookups= "false" redirectport= "8443" protocol= "ajp/1.3"/> Where the port is set in front <Proxy>, and the route is configured with the following code:
<!--Define The top level container at our container hierarchy-->
<engine name= "Catalina" defaulthost= "localhost" jvmroute= "a" > Jvmroute must also be the same as the previous settings.

The following is a test of the configured load balance with JMeter, starting with two Tomcat servers and then starting Apache server,

Create a new test plan in JMeter, create a new test.jsp under Jsp-examples in two Tomcat servers (this JSP writes two sentences on its own), and then test, following is a partial sampler result:

HTTP Response Headers:
http/1.1 OK
Date:wed, June 2007 02:17:55 GMT
set-cookie:jsessionid=ac7ef1caa8c6b0feb68e77d7d375e2af.b; Path=/jsp-examples
Content-type:text/html;charset=iso-8859-1
Content-length:3
Keep-alive:timeout=5, max=79
Connection:keep-alive The red code above indicates that the route suffix is already attached to the Jsessionid in the user's HTTP request, and. b indicates that this request will be forwarded to the Tomcat server Route B.

You will find that a portion of the requested Jsessionid suffix is. A, which is forwarded to the Tomcat server for route A.