Distributed session storage solution
Session Stick
The Session Stick scheme is to forward each request of the client to the same server, which requires the load balancer to forward the request according to the session ID (SessionId) of each request.
This solution is relatively simple to implement, and is the same as the case of a single machine for a Web server. But it may bring the following problems:
1. If a server goes down or restarts, all session data on this machine will be lost.
2. The session identifier is the application layer information. If the load balancer wants to save the requests of the same session to the same web server, the application layer (layer 7) needs to be parsed, and the overhead is larger than that of the fourth layer.
3. The load balancer will become a stateful node that holds the mapping of sessions to specific web servers. Compared with stateless nodes, memory consumption is larger and disaster recovery is more troublesome.
Session Replication
The Session Replication scheme does not change the load balancer, but adds the function of session data synchronization between web servers. The synchronization between each server ensures the consistency of session data between different web servers.
The Session Replication scheme no longer requires a load balancer, but it also brings the following problems:
1. Synchronizing session data will cause additional network bandwidth overhead. As long as the session data changes, the newly generated session data needs to be synchronized to other servers. The more servers there are, the greater the network bandwidth overhead caused by synchronization. .
2. Each web server needs to save all session data. If the number of sessions in the entire cluster is too large, the occupancy of each machine for saving session data will be very serious.
Session data is stored centrally
The session data centralized storage solution is to centrally store all sessions in the cluster. The web server itself does not store session data. Different web servers obtain sessions from the same place.
Compared with the Session Replication scheme, the session data of this scheme will not be stored in the local machine, and there is no replication of session data between web servers, but the problems of this scheme are:
1. Reading and writing session data introduces network operations. Compared with local data reading, the problem lies in the existence of delay and instability. However, if the communication occurs on the intranet, the problem is not serious.
2. If there is a problem with the machine or cluster that centrally stores the session, it will affect the application.
Cookie Based
The Cookie Based solution puts the session data in a cookie, and when accessing the web server, the web server generates the corresponding session data
However, the Cookie Based solution still has shortcomings:
1. Cookie length limitation. This will result in a Session length limit.
2. Security. Session data is originally server-side data, but it is stored on the client-side. Even if it can be encrypted, it is still insecure.
3. Bandwidth consumption. This is not referring to the bandwidth consumption between internal web servers, but the overall external bandwidth consumption of the data center.
4. Performance Impact. Each HTTP request and response carries the Seesion data. For the Web server, under the same processing conditions, the less the result output of the response, the higher the concurrency supported.
Summarize
The first four solutions are feasible, but for large websites, Session Sticky and Session data centralized storage are better solutions.
refer to
http://blog.csdn.net/t894690230/article/details/50477923
"Large website system and Java middle price practice"