Analysis and solution of conversational stickiness problem in Nignx connecting Tomcat _nginx

In the context of multiple background servers, we are bound to use long connections to ensure that one client communicates with only one server. Use what way to realize this kind of connection, common have use Nginx to do with the Ip_hash, I think this is definitely not a good way, if the front-end is CDN, or a local area network client simultaneously access the server, resulting in uneven server distribution, and the inability to guarantee that each access is sticky on the same server. If it's a cookie based on what kind of situation, think about it, each computer will have a different cookie, while maintaining a long connection while also ensuring that the server pressure balance.

Problem Analysis:

1. At the beginning of the request, there is no session information, Jvm_route according to round robin's method, sent to a tomcat above.

2. Tomcat adds the session information and returns it to the customer.

3. When the user requests this, Jvm_route sees the name of the backend server in the session, and it transfers the request to the corresponding server.

The default fair mode is not supported for temporary jvm_route modules. Jvm_route's working mode and fair are in conflict. For a particular user, the number of times that it retries the max_fails by default, and if it fails, re-enable the round robin mode, in which case the user's session will be lost, if the Tomcat has been serviced for him.

In general, the Jvm_route is to implement session stickiness by Session_cookie this way, attaching a particular session to a particular tomcat, thus solving the sessions ' different steps, but not resolving the problem of post downtime.
Without this jvm_route, if the user requests again, because there is no session information, NIGNX will again randomly send requests to the back-end of the Tomcat server, this situation, for ordinary page access is no problem. For requests with logon authentication information, the result is that the application server will never be logged in.
This module gets the session sticky by the way the session cookie is used. If there is no session in the cookie and URL, this is just a simple round-robin load balancing.

To solve the above similar problems, from the Internet to check, there are roughly the following ways:

1) Ip_hash (not recommended)

The Ip_hash technology in Nginx can direct an IP request to the same backend, so that a client under this IP and a backend can establish a solid session,ip_hash is defined in the upstream configuration:

Upstream Backend {
Server 192.168.12.10:8080;
Server 192.168.12.11:9090;
Ip_hash;
}

The reasons for not recommending use are as follows:

1/nginx is not the most front-end server.

Ip_hash requirements Nginx must be the most front-end server, otherwise nginx not get the correct IP, can not be based on IP hash. For example, the use of squid as the most front-end, then Nginx IP can only get Squid server IP address, using this address to shunt is definitely confused.

There are other ways of load balancing on the back end of the 2/nginx.

If there is another load balance on the back end of the Nginx and the request is diverted in another way, then a client's request must not be positioned on the same session application server.

3/multiple extranet exits.

Many companies have more than one export network, multiple IP addresses, users visit the internet automatically switch IP. And that's a few things. Using Ip_hash is not valid for a user in this situation and cannot bind a user to a fixed tomcat.

2) nginx_upstream_jvm_route (nginx extension, recommended)-I tried the next 1.8 version, found that the new version has not supported the!!! Wipe.. However, the 1.4.2 version is said to be supported.

Nginx_upstream_jvm_route is a nginx extension module that implements the function of the session Sticky based on cookies.

In short, it is based on the Jsessionid in the cookie to decide which server,nginx_upstream_jvm_route to send the request to the backend when the user requests the backend server for the first time. Bind the server identity of the response to the Jsessionid in the cookie, so that when the user initiates the next request, Nginx will decide which backend server to process according to the Jsessionid.

1/nginx_upstream_jvm_route Installation

Download Address (SVN): http://nginx-upstream-jvm-route.googlecode.com/svn/trunk/

Suppose the Nginx_upstream_jvm_route download path is/usr/local/nginx_upstream_jvm_route,

(1) Enter the Nginx source path

Patch-p0 </usr/local/nginx_upstream_jvm_route/jvm_route.patch

(2)./configure--with-http_stub_status_module--with-http_ssl_module--prefix=/usr/local/nginx--with-pcre=/usr/ local/pcre-8.33--add-module=/usr/local/nginx_upstream_jvm_route

(3) Make & make Install

2/nginx Configuration

Upstream Tomcats_jvm_route
{
# ip_hash;
Server 192.168.33.10:8090 srun_id=tomcat01;
Server 192.168.33.11:8090 srun_id=tomcat02;
Jvm_route $cookie _jsessionid|sessionid Reverse;
}

3/tomcat Configuration

Modify 192.168.33.10:8090tomcat's Server.xml,

Will

<engine name= "Catalina" defaulthost= "localhost" >

Modified to:

<engine name= "Catalina" defaulthost= "localhost" jvmroute= "tomcat01" >

In the same vein, add jvmroute= "tomcat02" to the 192.168.33.11:8090server.xml.

4/test

Start Tomcat and Nginx, access the Nginx proxy, use Google Browser, F12, view the Jsessionid in the cookie,
Like: abcd123456oiuh897sdfsdf.tomcat01, refresh will not change

3) Nginx sticky module based on cookies