Session sharing of distributed cluster tomcat+redis

　　What is Session/Cookie?

　　Users use the services of the website, which basically requires multiple interactions between the browser and the web server. The HTTP protocol itself is stateless. When the user's first access request ends, the back-end server cannot know whether the next access is the same as the last access user. We need a mechanism based on the HTTP protocol to support session state, such a mechanism that allows the web server to know which requests are from which session from multiple separate HTTP requests.

　　The role of Session and Cookie is to maintain the interactive state between the visiting user and the back-end server.

　　Understanding Cookies

　　The function of cookies is that when a user accesses a server through the HTTP protocol, the server will return some Key/Value key-value pairs to the client browser, and add some restrictions to the data, if the conditions are met When the user accesses the server next time, the data is brought back to the server in its entirety.

　　 Understanding Session

　　Cookies can allow the server program to track the access of each client, but these cookies must be returned each time the client accesses. If there are many cookies, this will invisibly increase the amount of data transmission between the client and the server, and the emergence of Session is exactly the To solve this problem.

        Every time the same client interacts with the server, it does not need to return all cookie values ​​every time, but only needs to return a session ID (SessionId), which is generated when the client accesses the server for the first time. , and each client is unique. In this way, each client has a unique ID, and the client only needs to return this ID. This ID is usually a cookie whose name is JSESIONID. On the Web server, each session stores information about different sessions independently. If you encounter the situation of disabling cookies, the general practice is to put the session ID in the parameters of the URL.

　　Summarize

　　Both cookies and sessions are designed to maintain a continuous state of user access. The reason for maintaining this state is to facilitate business implementation on the one hand, and to simplify server-side programming and improve access performance on the other. But it also brings some problems, such as security issues, Session synchronization issues in a cluster environment, etc.

　　Problems encountered by the cluster

　　When our application server becomes multiple, we will encounter the problem of Session sharing. When we visit the website for the first time, the load balancing assigns the local request to the web server 1, then the session is created on the web server 1. If we do not process it for the second time, we cannot guarantee that it will still fall to the web server. 1 too.

　　Solve the problem of cluster session sharing

　　 1. Session Sticky

　　The load balancer can forward the request according to the session ID of each request, so as to ensure that it can fall on the same server every time. This method is called the Session Sticky method. As shown below:

　　

　　There is a problem:

　　1. If the web server goes down or restarts, the session data on the server will be lost, and the user needs to log in again.

　　2. The session identifier is the information of the application layer, so if the load balancer wants to save the requests of the same session to the same web server, it needs to parse the application layer, which is more expensive than the fourth layer switching (LVS load balancing). device belongs to the fourth layer) should be larger.

　　3. The load balancer becomes a stateful node that holds the mapping of sessions to specific web servers. Compared with stateless nodes, the memory consumption will be larger and the disaster recovery will be more troublesome.

 

　　For example, the Web server is a restaurant, and the session data is tableware. If I want to ensure that I use my own tableware and chopsticks every time I eat, I will store the tableware in a certain restaurant, and I will go to this restaurant every time to eat.

　　2. Session Replication

　　Taking the example of eating, if we keep a set of our own tableware in each restaurant, we can choose which one to eat. This is Session Replication. As shown below:

　　

　　This solution no longer requires the load balancer to ensure that multiple requests for the same session must go to the same web server. We have added synchronization of session data between web servers, which ensures the consistency of session data between different web servers. Generally, application containers support the Session Replication mode. Compared with the Session Sticky solution, the Session Replication mode does not have so many requirements on the load balancer.

　　There is a problem:

　　1. Synchronizing session data causes network bandwidth overhead. As long as the session data changes, the data needs to be synchronized to all other machines. The more machines, the greater the network bandwidth overhead caused by synchronization.

　　2. Each web server must save all session data. If the entire cluster has a lot of session data (many people visit the website at the same time), the content of each machine for saving session data will be very heavy.

 

　　This solution relies on the application container to complete the replication of the Session to solve the problem of the Session. The application itself does not care about this matter. This solution is not suitable for scenarios with a large number of cluster machines. If there are only a few machines, this solution is fine.

　　3. Centralized storage of session data

　　The session data is stored centrally, and then different web servers obtain the session from the same place, as shown in the following figure:

　　

　　Session data is not saved to the local machine but is stored in a centralized storage place. Modifying the session also occurs in the centralized storage place. Web servers use Sessions to read from a centralized store. This ensures that the session data read by different web servers are the same. The specific way of storing the session can be a database, a distributed storage system, etc. This solution solves the problem of memory in the Session Replication solution, and is better than Session Replication for network bandwidth.

　　There is a problem:

　　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, our communication basically occurs on the intranet, and the problem is not big.

　　2. If there is a problem with the machine or cluster that centrally stores the session, it will affect our application.

 

　　Compared with Session Replication, when the number of Web servers is relatively large and the number of sessions is relatively large, the advantages of this centralized storage solution are very obvious.

　　4. Cookie Based

　　This solution also does not limit the specific processing machine for different requests of the same session. It passes Session data through cookies, as shown below:

　　

　　As can be seen from the above figure, our session data is placed in a cookie, and then the corresponding session data is generated from the cookie on the web server. It's like we bring our own bowls and chopsticks with us every time, so that we can choose at will when we go to the restaurant. Compared with the previous centralized storage solution, it does not rely on external storage systems, so there is no network delay and instability for acquiring and writing session data from external systems.

　　There is a problem:

　　1. Cookie length limitation. We know that cookies have a length limit, which also limits the length of Session data.

　　2. Security. Session data is originally server-side data, and this solution allows these server-side data to be sent to external networks and clients, so there are security issues. We can encrypt the session data of the written cookie, but for security, physical inaccessibility is safe.

　　3. Bandwidth consumption. Refers to the overall external bandwidth consumption of our data center.

　　4. Performance Impact. Each HTTP request and response carries Session data. For the Web server, under the same processing conditions, the less the result output of the response, the more concurrent requests it supports. Generating Session data also affects processing speed.

 

　　These four solutions are all available, but for large websites, Session Stick and Session data centralized storage are better solutions. These two solutions have their own advantages and disadvantages, and you need to make choices and trade-offs in specific scenarios. .

 

　　Below we introduce a simple example of the third solution for centralized storage of session data

　　

　　 Simple session sharing of tomcat7+redis realizes  the use of tomcat-redis-session-manager open source project

　　1. Download the open source project

 　　https://github.com/jcoleman/tomcat-redis-session-manager

　　2. After downloading the code, you need to recompile, generate the required jar, create a maven project arbitrarily, and copy the code under src to a specific location

　　The pom.xml file of maven is as follows:　　

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.ufind.session</groupId>
    <artifactId>tomcat-redis-session</artifactId>
    <version>1.0-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>org.apache.tomcat</groupId>
            <artifactId>tomcat-catalina</artifactId>
            <version>7.0.27</version>
        </dependency>
        <dependency>
            <groupId>redis.clients</groupId>
            <artifactId>jedis</artifactId>
            <version>2.7.2</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.0</version>
                <configuration>
                    <source>1.7</source>
                    <target>1.7</target>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>

　　3. Then open the terminal and execute mvn clean and mvn install to package the compiled code as: tomcat-redis-session-1.0-SNAPSHOT.jar.

　　4. Put the implementation package and dependency package commons-pool2-2.3.jar, jedis-2.7.2.jar, tomcat_redis_session-0.0.1-SNAPSHOT.jar package in the lib directory under the tomcat1 and tomcat2 instances respectively.

　　Download these three jars for free: http://download.csdn.net/detail/u010870518/9585716

　　5. Modify the conf/contex.xml file under the tomcat instance and add the configuration　　

<?xml version='1.0' encoding='utf-8'?>  
<Context>  
    <WatchedResource>WEB-INF/web.xml</WatchedResource>  

    <!-- tomcat-redis-session共享配置 -->  
    <Valve className="com.orangefunction.tomcat.redissessions.RedisSessionHandlerValve" />  
        <Manager className="com.orangefunction.tomcat.redissessions.RedisSessionManager"  
         host="192.168.1.149"   
         port="6379"   
         database="0"  
         password="redispassword" 
         maxInactiveInterval="60" />  

</Context> 

　　Summarize:

　　To sum up, if you want to achieve session sharing in Nginx, you must understand the way of session sharing. You can read my previous article to learn about it. The best way is to reduce session replication between Tomcats. The IO replication process will cause network congestion. By reloading the session management plug-in, the session can be shared by caching.

　　Reference link:

　　http://blog.csdn.net/Jerome_s/article/details/52658946

　　 http://blog.csdn.net/xlgen157387/article/details/52024139