1. Background
After setting up the cluster environment, one issue that has to be considered is how to deal with the session generated by user access. If nothing is done, users will log in frequently. For example, there are two servers A and B in the cluster. When a user visits the website for the first time, Nginx forwards user requests to server A through its load balancing mechanism. At that time, the A server will create a Session for the user. When the user sends a request for the second time, Nginx will load balance it to server B. At this time, server B does not have a session, so the user will be kicked to the login page. This will greatly reduce the user experience and lead to the loss of users. This situation should never occur in the project.
Two, session processing strategy
2.1 Session Sticky management
For example, as seen in the following figure:
Server independent Session requires that every request of the user must be operated on the same application server, which requires the load balancing server to send the user's request to the server with the same address every time.
The first server accessed by the first user for the first time. That in the user's entire session must be diverted from the load balancing server to the No. 1 server. Other servers will not save the session information of user No. 1.
Today's load balancing servers generally have this function (nginx)
But suppose the following situation occurs
At this time, when server 1 is down, the load balancing server will divert user 1 to server 2 or 3, but the user does not have a secure context on servers 2 and 3. The server will notify the user to log in again. This way the user experience will definitely be affected. And it is very likely to cause user data loss.
2.2 Session Replication management (ie session replication)
Each server keeps the session of all users, which is related to the session synchronization between application servers. Real-time requirements are relatively high.
This way can avoid the problems encountered by the server independent Session above, as shown in the following figure:
Strengths
In this way, even if the first situation occurs, the Session information of No. 1 is saved on servers 2 and 3. When a fault occurs, the load balancing server diverts user No. 1 to servers No. 2 and 3. The server will also find that there is the security context of user No. 1, which can continue to access and does not need to log in again.
Disadvantage
However, this method also has disadvantages, that is, the real-time requirements for session synchronization of the corresponding application server are relatively high, and it will bring additional cross-band overhead. And when there is a change in the distance of the session, it needs to be synchronized. Assume that the amount of information in the Session is relatively large. That will take up considerable memory consumption.
2.3 Centralized Cache Management
Server shares Session information:
Strengths
The session information of each user will be stored in another server outside the application (it may be a database, or it may be a KV storage service), so that the application server does not need to store the session information of each user, which saves a lot of money Memory overhead.
When different application servers need Session information, they go to the shared Sessionserver to get the information.
In this way, the load balancing server does not have to assign users to a server fixedly, and there is no need to copy Session information between servers. When the Session information changes, the application server can share the server change information.
Disadvantage
More dependent on the shared server, once the shared server or shared server cluster fails. Users will receive a very big impact