Session sharing between clusters

Session tracking
We know that the session mechanism is completed by cookie or Url rewriting under stand-alone conditions. The specific method is to create a session and create a cookie and jsessionid (the String field is used to identify the session) when the user first requests the getSession method. And rewrite the line with all the URLs in the page (the guy snag the jsessionid at the end), and send it to the client. The client makes another request (including information about whether cookies are allowed), this time the request has been URL rewritten by the server, so the session is tracked. When the server accepts this request, it will determine whether the cookie is accepted by the client browser. If the cookie is not accepted, then continue to use URL rewriting to achieve session tracking. If the cookie is accepted, it is preferred to use cookie to achieve session tracking.
Session data structure
In servlet/jsp, what data structure does the container use to store session-related variables?

       Let's guess, first of all, it must be operated synchronously, because in a multi-threaded environment, sessions are shared between threads, and web servers are generally multi-threaded (pooling technology is also used to improve performance); second, this Data structures must be easy to manipulate, preferably traditional key-value access.


    So let's start with a single session object. In addition to storing its own related information, such as id, the session of tomcat also provides an interface for programmers to store other information (in the class org.apache.catalina.session.StandardSession inside):

Java code collection code
public void setAttribute(String name, Object value, boolean notify) 
protected java.util.Map attributes
          The collection of user data attributes associated with this Session.
Then its attribute attribute is a Map structure, so obviously for thread-safe Map structures, we prefer ConcurrentHashMap as its specific object, which is the concurrent package of java a class in . It does exactly what we guessed at two needs: synchronization and ease of operation.

So what data structure does tomcat use to store all session objects? Sure enough, it is ConcurrentHashMap (in the org.apache.catalina.session.ManagerBase class that manages sessions):

protected Map<String, Session> sessions = new ConcurrentHashMap<String, Session>();

The specific reasons do not need to be said. As for the specific implementation of other web servers, these two points should also be considered.


Session mechanism in a cluster environment
Now due to the increasing development of the Internet, the traffic of many websites is also increasing day by day, and the single server and database can no longer withstand the pressure of our website access, so the current system is made into a distributed cluster to To solve the requirements of large concurrent and large data volume, Taobao is a very classic example. Cool So here comes the question. Multiple requests sent by a client are processed by a polymorphic server. How do we implement session sharing on a distributed polymorphic machine for the cookie or url rewriting requests sent by the client?
In general, sessions cannot exist across servers. Here are several ways to share sessions:
            The first is the client-side solution. The session is encrypted and stored in the cookie. Each session information is written on the client side, and then submitted to the server again through the browser. Even if the two requests are completed on two servers in the cluster, Session sharing can also be achieved. The advantage of this solution is that the session information does not need to be stored on the server side, which greatly reduces the pressure on the server. Another advantage is that two or more requests in a session can be multiple in a cluster. Completed on the server, it can avoid single-ended failure. At present, Taobao adopts this solution. We may be unfamiliar with the cookie-based session sharing solution, but it is still widely used in large websites. The principle is to encrypt and serialize the session information of the users of the whole site and plant them in the root domain name in the form of cookies. Corresponding characteristics of all cookie content, so as to realize the shared access of the user's cookie-based session among multiple services. The advantage of this scheme does not require additional server resources; the disadvantage is that due to the limitation of the length of the http protocol header, only a small part of user information can be stored, and the cookie-based session content needs to be encrypted and decrypted securely (for example, using DES, RSA, etc. Plaintext encryption and decryption; then anti-counterfeiting authentication is performed by MD5, SHA-1 and other algorithms), and it will also occupy a certain bandwidth resource, because the browser will attach the local cookie to the http header when requesting any resources under the current domain name. server.
            The second is to provide a cluster to save session shared information. All other applications store their own session information in the session cluster server group. When the application system needs session information, it directly reads from the session cluster server. This method has the first The second advantage of this method is that Taobao may also use this method now. They don't know the specific session sharing framework they use.

There is a buddy who is studying bboss's session sharing framework:
The bboss session sharing framework can quickly realize session sharing between cluster nodes and cross-domain and cross-application session sharing. It is independent of specific containers, can count the number of online sessions, and manage application sessions in the unified monitoring center (deleting sessions, querying session data, etc.) , References: bboss
session sharing demo user guide             bboss session
sharing architecture and features The session information is sent to the salve. After a server is down, the user's request is transparently forwarded to other servers in the cluster through the balance server. At this time, the backup session information needs to be read from the salve. But this method is more personal. Hey, this method means that the server saves the session of a specific user and then allows the user to access the server every time, so there is no problem of session sharing. At the same time, this server also has salve as a backup. If it is dropped, then it is necessary to put it on the Salve.   Recommend a good summary for everyone: Taobao technical architecture