Session sharing problem caused by load balancing using Nginx

PHP server has more than one, with nginx load balancer, so that the same IP access to the same page will be assigned to different servers, if the session is not synchronized, there will be many problems, such as the most common login status, the following provides several ways to solve the problem of session sharing:

1. Do not use session, swap with cookies

The session is stored on the server side, the cookie is stored on the client, we can put the user access page generated by the session into the cookie, is to use a cookie as a transit point. You visit Web Server A, generate a session and then put it into the cookie, when your request is assigned to the B server, Server B first determine whether the server has this session, if not, then to see if there is a client cookie in this session, If not, the session really does not exist, if there is a cookie, the cookie inside the Sessoin synchronization to Server B, so that the session synchronization can be achieved.

Note: This method is simple, convenient, and will not increase the burden of the database, but if the client has forbidden the cookie, then the session will not be synchronized, this will bring a loss to the site, the security of the cookie is not high, although it has been added, but still can be forged.

2, the session exists in the database (MySQL, etc.)

PHP can be configured to save the session in the database, this method is to put the table and other database tables to hold the session together, if MySQL also made a cluster, each MySQL node must have this table, and this session table data table to synchronize in real time.

Note: Using the database to synchronize the session, the database will be increased IO, increase the burden of the database. and the database reading and writing speed is slow, not conducive to timely synchronization session.

3. Session exists in Memcache or Redis

Memcache can be distributed, the PHP configuration file is stored in memcache, so PHP itself will create a session cluster, the session data stored in the memcache.

Note: In this way to synchronize the session, will not increase the burden of the database, and security than with cookies greatly improved, put the session into memory, than from the file read much faster. But memcache the memory into many kinds of storage blocks, there is a block size, this way also determines that the memcache can not fully utilize the memory, will produce memory fragmentation, if the storage block is insufficient, but also generate memory overflow.

4. 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:
[HTML] View plaincopy on code to see a snippet derived from my Code slice
Upstream nginx.example.com
{
Server 192.168.74.235:80;
Server 192.168.74.236:80;
Ip_hash;
}
Server
{
Listen 80;
Location/
{
Proxy_pass
http://nginx.example.com;
}
}

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.
The back end of the 2.nginx also has other ways of load balancing.

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.

5, 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. I never really knew what I was trying to do.

Session sharing problem caused by load balancing using Nginx