Example of a shared sessions session configuration method in Nginx _nginx

Sessions are generally referred to as time domains. In computer terminology, session refers to the time interval between an end user communicating with an interactive system, usually the time elapsed between the registration entry system and the logout exit system and, if necessary, some room for operation.

Sessions are generally referred to as time domains. In computer terminology, session refers to the time interval between an end user communicating with an interactive system, usually the time elapsed between the registration entry system and the logout exit system and, if necessary, some room for operation.

Usually the session can be changed to a cookie, you can avoid some of the drawbacks of the session, in the past to see a book of the Java-EE, also indicated in the cluster system can not use session, otherwise provoke out of scourge to be difficult to do. If the system is not complex, prioritize the session can be removed, the change is very cumbersome, and then use the following method.

The application server realizes sharing by itself

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

All of the above two methods have nothing to do with Nginx, the following is said with Nginx how to deal with:

Ip_hash

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

Copy Code code as follows:

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 the backend, 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, 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.

2, the back end of the nginx there are other ways of load balancing. 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. In this way, the Nginx backend can only point directly to the application server, or a squid, and then point to the application server. The best way to do this is to use location for a diversion, which will require part of the session to be diverted through Ip_hash, leaving the rest to the back end.

Upstream_hash

To solve some of the ip_hash problems, you can use Upstream_hash, a 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 the head to do the factor, the request to the specified back end:

Copy Code code as follows:

Hash $http _x_forwarded_for;

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

Copy Code code as follows:

Hash $cookie _jsessionid;