Tomcat cluster session management solution (about sticky session, session replication and memcached cache session)

The original Article connection: http://blog.csdn.net/bluishglc/article/details/7641714, reproduced please indicate the source!

Abstract: The main purpose of this article is to explain some important concepts in the cluster solution, and then introduce another session management mechanism: cache-based session management. This article does not describe how to configure Apache and tomcat to achieve cluster and load balancing. For more information, see my other article: Set up a full record of Tomcat clusters in Linux.

1. What problems do I need to solve to implement the application server cluster?

For all Application Server Clusters, two basic and core problems must be solved:

1. How to distribute access requests to all nodes in the Cluster
2. How to use a session management policy to ensure that the session data of a node becomes invalid and can be obtained from other nodes so that other nodes can replace the failed node to implement fault tolerance (Failover) of the Cluster)

For the first problem, the simplest and most straightforward idea is, of course, uniformly hashes requests to each node, but for the application server, due to the existence of session, A better way is to distribute requests from the same session to the same node for processing. This is called sticky session load balancing, the former is called non-sticky session load balancing.

For the second problem, most servers (including Tomcat) should use the session replication mechanism, that is, each node sends its own session to all other nodes through multicast. If one of the nodes fails to access the session, the other node still has valid session content, so that it can take over the session normally. Because the server has built-in session replication mechanism implementation, it is very simple to use this solution. You only need to do simple configuration, but its disadvantages are also obvious, because a large amount of session information needs to be copied, session replication may become a performance bottleneck when the number of users and the number of clusters reaches a certain scale. So people think of another solution: the sessiono data is stored in a third-party cache. If a node fails, the server appointed to replace the node with the invalid node can recover the session from the cache. based on this idea
Code has an open-source product: memcached-session-manager.

2. How memcached-session-Manager works

First, all Tomcat nodes need to install memcached-session-manager. Each Tomcat node has its own local session. After a request is executed, if the corresponding session does not exist before (that is, this is the first request of a user), copy a copy of the session to the memcached cache. When the next request of the session arrives, the local session of Tomcat will be used. After the request processing is complete, the session changes will be synchronously updated to the corresponding session in the memcached cache to ensure that the local session and the session in the cache are consistent. If the current node fails, the next request will be routed to another tomcat for processing. This tomcat finds that the session to which the request belongs does not exist, so it will query the memcached cache, then, the queried session is restored to the local machine, thus fault tolerance Processing is completed. (The above is sticky.
The session mode is the background explanation. memcached-session-Manager also supports non-sticky sessions .)

Because cache-based session management does not require a large amount of data replication, it provides better performance and better scalability.

Last added: In fact, apart from the server-side session management, there is another completely different management method, the session is compressed and encrypted as part of the cookie and stored in the user's local browser!