An example of the session session configuration method is Shared in Nginx

Session1 generally refers to the time domain. In computer terms, Session refers to the time interval between an end user's communication with an interactive system, usually the time between the time it takes to register with the system and the time it takes to log out of the system and, if necessary, the amount of operating space available.

Session1 generally refers to the time domain. In computer terms, Session refers to the time interval between an end user's communication with an interactive system, usually the time elapsed between registration into the system and logout of the system and, if necessary, a definite amount of operating space.

In general, if you can change session to cookie, you can avoid some of the disadvantages of session. In the previous book of J2EE, it is also pointed out that session cannot be used in the cluster system, otherwise it will be difficult to deal with the disaster. If the system is not complex, consider whether session can be removed first. If it is very troublesome to change it, use the following method.

The application server implements its own sharing

It is known that php can use the database or memcached to save session, thus setting up an session cluster in php itself. In this way, session can guarantee the stability of session, and session will not be lost even if a node fails. It is suitable for strict situations with low demand. But its efficiency is not very high, does not apply to the high efficiency request occasion.

Neither of the above two methods has anything to do with nginx. Here is what to do with nginx:

ip_hash

The ip_hash technology in nginx directs an ip request to the same back end so that a client and a back end under ip are firmly established
session, ip_hash are 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 factor ip can be used to assign the back end, ip_hash is defective and cannot be used in some situations:

1. nginx is not the most front-end server. ip_hash requires that nginx1 must be the most front-end server, otherwise nginx cannot be ip correctly, so hash cannot be made according to ip. For example, if squid is used as the most front-end, then nginx can only get the squid server ip address when ip is taken from nginx. It is definitely wrong to use this address for shunt.

2. There are other ways of load balancing in the back end of nginx. If the nginx backend is load-balanced and the request is diverted in a different way, then a client's request cannot be located on the same session application server. In this way, the nginx backend can only point directly to the application server, or it can take another squid and point to the application server. The best way to do this is to do a shunt with location. Part of the request that requires session is diverted through ip_hash and the rest goes to the other backend.

upstream_hash

In order to solve some of the problems of ip_hash, you can use upstream_hash as a third party module. This module is mostly used as url_hash, but it does not prevent it from being used for session sharing:
If the front-end is squid, he will add ip to x_forwarded_for and http_header. upstream_hash can use this header as a factor to direct the request to the specified backend:

hash $http_x_forwarded_for;

This has been changed to use the header x_forwarded_for as a factor. In the new version of nginx, cookie can be read, so it can also be changed to:

hash $cookie_jsessionid;