Several ways for nginx load balancer to handle session sharing

1) Instead of using session, use cookie

If you can change session to cookie, you can avoid some of the disadvantages of session. In a J2EE book I read before, it also pointed out that session cannot be used in a cluster system, otherwise It will be difficult to handle if trouble occurs. If the system is not complex, give priority to whether the session can be removed. If it is very troublesome to change, then use the following method.

2) The application server realizes sharing by itself

It is known that PHP can use a database or memcached to save the session, thereby establishing a session cluster in PHP itself. In this way, the session can be guaranteed to be stable, even if a node has In the event of a failure, the session will not be lost, and it is suitable for more stringent situations but low request volume. However, its efficiency is not very high and it is not suitable for occasions that require high efficiency.

The above two methods have nothing to do with nginx. Let’s talk about how to use nginx:

3) ip_hash

The ip_hash technology in nginx can direct the request of a certain IP to the same backend, so that A stable session can be established by going to a client and a backend under this IP. 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 only the ip factor can be used to allocate backends, ip_hash is defective and cannot be used in some cases:

1/ nginx is not the front-end server. ip_hash requires that nginx must be the front-end server. Otherwise, nginx cannot get the correct IP and cannot hash based on the IP. For example, if Squid is used as the front end, then nginx can only get the server IP address of Squid when fetching the IP. It is definitely confusing to use this address for distribution.

2/ The backend of nginx also has other methods of load balancing. If there are other load balancing on the nginx backend and the requests are diverted in another way, then a request from a certain client will definitely not be located on the same session application server. Calculating this, the nginx backend can only point directly to the application server, or build a Squid and then point to the application server. The best way is to use location as a diversion, divert some requests that require session through ip_hash, and go to other backends for the rest.

4) upstream_hash

In order to solve some problems of ip_hash, you can use the third-party module upstream_hash. This module is used as url_hash in most cases, but it does not prevent it from being used for session sharing:

If the front-end is Squid, it will add the ip to the x_forwarded_for http_header. Using upstream_hash, you can use this header as a factor to direct the request to the specified backend:

See this document:

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

In the document, $request_uri is used as the factor. Change it slightly:

hash $http_x_forwarded_for;

In this way, it is changed to use the x_forwarded_for header as the factor. In the new version of nginx, it can support reading cookies value, so it can also be changed to:

hash $cookie_jsessionid;

If the session configured in php is cookie-less, with nginx’s own userid_module module, you can use nginx to generate a cookie