https://blog.csdn.net/u012081441/article/details/71787164
I have written about building an nginx environment in the ubuntu environment before. Today, I will talk about the nginx session sharing problem. I have checked some information and read some documents written by others. The summary is as follows. There are many shared servers for nginx session, and nginx is used as the load. Balanced, 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 session sharing problem. question:
1. Do not use session, use cookie instead
The session is stored on the server side, and the cookie is stored on the client side. We can put the session generated by the user accessing 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 not, then go to see if the client's cookie contains 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.)
You can configure the session to be stored in the database. This method is to put the session table and other database tables together. If mysql is also clustered, each mysql node must have this table and this session. The data table of the table should be synchronized in real time.
Note: Using the database to synchronize sessions 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 redis
Memcache can be distributed, and the storage method is set to memcache in the program configuration file, so that the program 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. ip_hash technology in nginx
It 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 defined in the upstream configuration:
upstream nginx.example.com
{
server 127.0.0.1:8080;
server 127.0.0.1:808;
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 most front-end server.
ip_hash requires nginx to 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 fetching ip. Using this address for shunting is definitely confusing.
<2> There are other ways of load balancing in 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 shunt, and shunt some requests that need session through ip_hash, and the rest go to other backends.
5、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.
<1> fair (third party)
allocates requests according to the response time of the back-end server, and priority is given to those with short response time.
upstream resinserver{
server server1;
server server2;
fair;
}
<2> url_hash (third party)
allocates requests according to the hash result of accessing the url, so that each url is directed to the same back-end server, which is more effective when the back-end server is cached.
Example: add a hash statement to the upstream, other parameters such as weight cannot be written in the server statement, hash_method is the hash algorithm used
upstream resinserver{
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
tips:
upstream resinserver{#Define the IP and device status of the load balancing device
ip_hash;
server 127.0.0.1:8000 down;
server 127.0.0.1:8080 weight=2;
server 127.0.0.1:6801;
server 127.0.0.1:6802 backup;
}
Add proxy_pass http://resinserver/ to the server that needs to use load balancing ;