Solve the session sharing problem of nginx load balancing (reproduced)

I checked some information and read some documents written by others. The summary is as follows. There

are multiple shared PHP servers for nginx session, and nginx is used for load balancing, so that accessing the same page from the same IP 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. Instead of using a session, use a cookie instead. The

session is stored on the server side, and cookies are stored on the server side. It is stored on the client side. We can put the session generated by the user visiting the page into the cookie, which is to use the cookie as a transfer station. You visit web server A, generate a session and put it in the cookie. When your request is assigned to server B, server B first determines whether the server has this session. If there is no such session, if it does not, it means that the session does not exist. If there is one in the cookie, synchronize the session in the cookie to server B, so that the synchronization of the session can be realized.

Description: This method is simple and convenient to implement, and will not increase the burden on the database, but if the client disables cookies, the session will not be synchronized, which will bring losses to the website; the security of cookies Not high, although it has been encrypted, it can still 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 session table and other database tables together. If mysql is also clustered, each mysql node There must be this table, and the data table of this session table must be synchronized in real time.

Note: Using the database to synchronize the session will increase the IO of the database and increase the burden on the database. Moreover, the database read and write speed is slow, which is not conducive to the timely synchronization of sessions.

3. The session exists in memcache or memcache in redis

can be distributed, and the storage method is set to memcache in the php configuration file, so that php itself will establish a session cluster and store session data in memcache.

Note: Synchronizing sessions in this way will not increase the burden on the database, and the security is greatly improved compared to using cookies. Putting sessions in memory is much faster than reading from files. However, memcache divides memory into storage blocks of various specifications, and there are blocks with sizes. This method also determines that memcache cannot fully utilize memory, resulting in memory fragmentation. If there are insufficient storage blocks, memory overflow will occur.

4. The ip_hash technology in nginx can direct the request of an ip to the same backend, so that a client and a backend under this ip can establish a stable session, ip_hash is configured in the upstream defined in:

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 only the ip factor can be used to allocate backends, ip_hash is flawed 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 it cannot hash according to the ip. For example, if Squid is used as the front end, then nginx can only get the IP address of Squid's server when it obtains the IP address. It is definitely confusing to use this address for distribution.
2. There are other ways of load balancing on the backend of nginx.

If the nginx backend has other load balancing, and the request is distributed in another way, then the request of a client 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 add a squid, and then point to the application server. The best way is to use location as a shunting, shunting some requests that require session through ip_hash, and the rest go to other backends.

5. upstream_hash
In order to solve some problems of ip_hash, the third-party module upstream_hash can be used. This module is mostly used as url_hash, but it does not prevent it from being used for session sharing. I haven't tried it, I really don't understand



. Reprinted from: https://blog.csdn.net/xluren/article/details/16951247