First, let's introduce load balancing and session, and take Nginx and session as an example:
1. Load balancing
The purpose is to balance the back-end server load through the reverse proxy server (Nginx), and try to avoid overloading a certain back-end server, thereby affecting the service.
The load balancing strategy provided by Nginx:
(1) Weighted polling (static weighting)
(2) The current minimum number of connections
(3) ip_hash
(4) url_hash (third-party module)
Among them: ip_hash also has a bad place, if one of the If a server is down, users mapped to this server cannot obtain services, and it is difficult to achieve load balancing.
2.Session keep
A problem can be found:
through polling, it is not guaranteed that the same user or users with the same ip can access a certain back-end server; but ip_hash is difficult to achieve load balancing like polling.
Let's talk about what session and cookie are:
session is an abstract concept. In order to achieve interrupt and resume operations, developers abstract the one-to-one interaction between user agent and server as "session", and then derive "session state". " , which is the concept of session. The cookie is an actual thing, a field defined in the header in the http protocol.
The "session" we often talk about today is to circumvent the various limitations of cookies, and is usually implemented with the help of the cookie itself and back-end storage, a more advanced session state implementation. Specific to the implementation, session is usually implemented with the help of cookie because of the existence of session id, but this is not necessary, it can only be said to be an implementation scheme with better versatility. And the session really can be saved by any object.
When load balancing performs request distribution, it ensures that each client has fixed access to the same application server on the backend. For example: from logging in = "photographing =" adding address = "payment, this is a series of processes, which can also be understood as a single operation process. All this series of operation processes should be completed by a server, not Distributed to different servers by the load balancer.
There is a time limit for session retention (except for servers that are mapped to a fixed one, such as: ip_hash); this can reduce the need to synchronize sessions, but it cannot be eliminated. So session synchronization/sharing still needs to be done.
3. Session synchronization/sharing
After building a web cluster, first consider the issue of session synchronization, because after load balancing, accessing the same page from the same IP will be assigned to different servers. If the sessions are not synchronized, a logged-in user will be logged in for a while. , and is not logged in for a while. So this article gives three different methods to solve this problem according to this situation:
1. Sticky session
Since the session identifier is the information of the application layer, the load balancing device should save the same session request to the same web server.
Disadvantages :
(1) It is necessary to analyze the application layer, and the overhead is larger than that in the transport layer.
(2) At this time, the load balancer has become a stateful node . To save the mapping of the session to the specific web server, compared with the stateless node, the memory is larger and the disaster recovery is more troublesome.
2. Synchronize between servers:
If you have done database read-write separation, you should know that when reading and writing is separated, you actually read the slave library and write to the master library, but the information of the master library will be updated to the slave library, regardless of the read and write time, we can It is considered that the data of the slave library and the master library are consistent, and this consistency is mainly achieved by synchronization.
When dealing with sessions, we can also adopt such a strategy. On the load balancing device, there is no need to do anything, and only stateless distribution is performed . Anyway, which server is distributed to, I have all previous sessions.
Disadvantages :
(1) Synchronizing sessions causes network bandwidth overhead. As long as session data changes, data needs to be synchronized to other servers. The more machines there are, the greater the network overhead caused by synchronization.
(2) Each web server must save all session information. If there is a lot of session data in the entire cluster, each application server will save a lot of session data, which will seriously occupy memory.
3. Use redis to share session
Since you don’t like synchronization, you should take out all session data and put it in a separate place, which can be a separate database or other distributed storage system. The front load balancer is still stateless forwarding , and the application server reads and writes the session every time. , all to the same place to pick up.
He can combine the memory in the web server into a large memory, no matter which server generates the sessoin can be placed in this "large memory", and all other servers can use it.
Advantages :
Synchronizing sessions in this way will not increase the burden on the database, and the security is greatly improved than using cookies. Putting sessions in memory is much faster than reading from files.
Disadvantages :
(1) Reading and writing session data introduces network operations. Compared with local data reading, the problem is that there is delay instability, but considering that the communication between the application server and the session storage device occurs in the Content, so, take it easy!
(2) If session storage is centralized, we must consider that when a problem occurs with the session server, it will affect the use of our entire chain.
4. Use cookies to synchronize sessions:
It is to put the session generated by the user visiting the page into the cookie, which is to use the cookie as a transit station. You visit web server A, generate a session and put it in the cookie. Your visit is assigned to web server B. At this time, web server B first determines whether the server has this session. If not, it will look at the client's cookie. Whether there is this session in it, if not, it means that the session really does not exist. If there is one in the cookie, synchronize the session in the cookie to the web server B, so that the synchronization of the session can be realized.
Disadvantages :
Cookie length limit: Because the length of data that a cookie can carry is limited;
Security: It can be encrypted, but it can still be forged;
Bandwidth consumption;
Performance: Each HTTP request and response has session data, which affects concurrent performance ; Because for the web server, in the same situation, the less the result output of the response, the more concurrent requests it supports.