Session Sticky management mode
Other servers do not store Session information of user 1.
Load balancing servers today typically have this functionality (nginx)
But suppose the following happens
When Server 1 is down, the load balancing server will divert user 1 to Server 2 or Server 3, but the user does not have a secure context on Server 2 or Server 3. The server notifies the user to log in again. The user experience will definitely suffer. And it is very likely to cause user data loss.
Session Replication Management (Session Replication)
Each server retains the Session of all users, which is related to the Session synchronization between application servers. The real time requirement is relatively high.
This approach avoids the problems encountered by server independent sessions above, as seen in the following figure:
strengths
In this way, even if the first situation occurs, the Session information of user 1 is stored on server 2 and server 3. When a failure occurs, the load balancer server diverts user 1 to server 2 and server 3. The server will also discover the security context of user 1 and be able to continue access without the need for another login.
disadvantages
However, this method also has disadvantages, that is, the corresponding use of server Session synchronization real-time requirements are relatively high, and will bring extra cross-band overhead. And when the Session distance changes, synchronization is required. Let’s say there’s a lot of information in the Session. That takes up quite a bit of memory consumption.
Centralized cache management
The server shares Session information:
strengths
The Session information of each user will be stored in another server (database or KV storage service) outside the application. In this way, the application server does not need to store the Session information of each user, saving huge memory overhead.
When different application servers need Session information, they go to the shared Session Server to get the information.
In this way, load balancing servers do not need to allocate users to one server, nor do they need to copy Session information between servers. When Session information changes, application servers share server change information.
disadvantages
It depends on the shared server. Once the shared server or the shared server cluster fails. Users will be greatly affected