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. A J2EE book I read before also stated that session cannot be used in cluster systems. , otherwise it will be difficult to handle if it causes trouble. 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 certain If a node fails, the session will not be lost. It is suitable for more strict 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 computer. end, so that a client and a backend under this IP can establish a stable 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 only the ip factor can be used to allocate backends, ip_hash is defective , cannot be used in some situations:

1/ nginx is not the most 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/ nginx’s backend 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. Calculated this way, 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;

This way, we use the x_forwarded_for header As a factor, the new version of nginx can support reading cookie values, so it can also be changed to:

hash $cookie_jsessionid;

If the session configured in php is cookie-less, use nginx's own one The userid_module module can use nginx to generate a cookie. Please refer to the English documentation of the userid module:

http://wiki.nginx.org/NginxHttpUserIdModule

The above introduces several methods for nginx load balancer to handle session sharing, including aspects of content. I hope it will be helpful to friends who are interested in PHP tutorials.