Several methods of dealing with session sharing with Nginx load balancer

1) Do not use the session, in exchange for cookies

Can change the session to a cookie, you can avoid some of the shortcomings of the session, in the previous read a book on the Java EE, also indicated in the cluster system can not use the session, or provoke out scourge to do. If the system is not complex, it is preferred to be able to remove the session, the change is very troublesome, then use the following method.

2) The application server realizes its own sharing

Known, PHP can use the database or memcached to save the session, so in PHP itself set up a session cluster, in such a way can make the session to ensure stability, even if a node has failed, the session will not be lost, Apply to the more stringent but not high demand for the occasion. But its efficiency is not very high, not for the high efficiency requirements of the occasion.

The above two methods are not related to Nginx, the following is how to deal with Nginx:

3) Ip_hash

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

Upstream Backend {
Server 127.0.0.1:8001;
Server 127.0.0.1:8002;
Ip_hash;
}

Ip_hash is easy to understand, but because the backend can only be assigned with the IP factor, the Ip_hash is flawed and cannot be used in some cases:

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

There are other ways to load balance the 2/nginx backend. If the Nginx backend has other load balancing, and the request is diverted in another way, then a client's request must not be located on the same session application server. In this way, the Nginx backend can only point directly to the application server, or another squid, then point to the application server. The best way is to use location for a diversion, will need to part of the session request through the Ip_hash shunt, the rest of the other back end.

4) Upstream_hash

To solve some of the ip_hash problems, you can use Upstream_hash, the third-party module, which is used in most cases as url_hash, but does not prevent it from being used for session sharing:

If the front end is squid, he will add IP to x_forwarded_for this http_header, with Upstream_hash can use this head to do the factor, the request directed to the specified backend:

This document is visible:

http://www.oschina.net/discuss/thread/622

In the document, use $request_uri as a factor and change it a little bit:

Hash $http _x_forwarded_for;

This is changed to use the x_forwarded_for as the first factor, in the new version of Nginx can support reading cookie value, so can also be changed to:

Hash $cookie _jsessionid;

If the session configured in PHP is no cookie, with Nginx own one of the Userid_module module can use Nginx spontaneous a cookie

