Session keep

 Session keep

1. Session essence

The http protocol is stateless, and the server is transparent to the client. There is no difference between visiting a webpage 100 times and visiting once for the server, because it cannot remember you.
 However, in some occasions, what if the server does need to remember the current user? For example, after a user logs in to their mailbox, they need to receive emails and write emails. It is impossible to ask the user to enter a username and password for each operation. In order to solve this problem, the session scheme has been proposed. In fact, it is not new. technology, but also cannot be separated from the http protocol and any existing web technology.

 

2. About Session Sharing

First of all, there is no problem of session sharing in a stand-alone environment, but high availability cannot be guaranteed, but what if you use load balancing to distribute requests to different machines? At this time, there is no problem with the session id on the client side, but if the user's two requests are sent to two different machines, and its session data may exist on one of the machines, the situation that the session data cannot be obtained will occur at this time. , so session sharing becomes a problem.

 

3. Session sharing solution

1. The Nginx load balancer is used, and the ip_hash is used instead of the default polling method , that is, the request of a client IP can be located on the same back-end web server through the hash algorithm, which avoids session loss and solves the problem. session problem.
However, the ip_hash command cannot guarantee the load balancing of the back-end servers. Some back-end servers may receive many requests, while some back-end servers receive few requests ; this loses the meaning of load balancing.

 

2. Write the user's login session information into the back-end Mysql database . This is also implemented in the later CMS system, and the effect is also good; however, using the database to synchronize the session will increase the IO of the database and increase the burden on the database . Moreover, the database read and write speed is slow, which is not conducive to the timely synchronization of sessions, and is not recommended.
Later, I came up with a compromise solution. If the number of concurrent connections of Nginx (that is, the active connections of NginxStatus of the Nginx load balancer) > 2000, the method of writing the session into the MySQL database is adopted; if the number of concurrent connections is small, the effect of ip_hash is quite good. .
Reference: http://blog.csdn.net/donggang1992/article/details/51095551

 

3. Session replication , suitable for when there are few access layer clusters, because session replication occupies server resources and storage occupies memory

For example, the session can be cached in redis to achieve the purpose of session replication. At present, this solution is implemented by nginx + redis + tomcat

4. Session binding, master-slave replication ************[ip_hsah did not attempt master-slave replication]**************

 

5. Client cookie saves Session

6. Session cluster

 

 

1. Use the filter method to store ( not implemented )

This method is recommended because it has a wide range of servers, not limited to tomcat, and the principle of implementation is relatively simple and easy to control.
You can use the official website of memcached-session-filter
: http://code.google.com/p/memcached-session-filter/Official
introduction: To solve the java web container session sharing in a cluster environment, use filter interceptor and memcached to achieve. It has passed the test on tomcat 6 and websphere 8. The current network has 2,000 concurrent transactions and 11 million daily PVs.
Session events including create destory and attribute change are not supported for
the time being. The size is very small, but this stuff needs
to of java. Serialization performance is also mediocre.
I simply extended it, no longer relying on spring, and using javolution to achieve serialization, the cached objects are no longer limited.
I haven't found the implementation of redis for the time being. Later, I will use redis to store my own implementation and use kyro for serialization. The details will be written out separately when I have time.

 

2. Session cluster sharing based on Tomcat itself ( not implemented )

Problem: Configuration completed, but invalid ;

The reference is: tomcat session sharing;

 

 

3. Use the tomcat session manager method to store

In this method, the server can only use tomcat, but there are implementations for memcached and redis on the Internet, which can be configured directly. For Redis, it has been practiced

1. Environmental preparation

Tomcat cluster

IP	CPU name	The port number
192.168.1.111	edu-web-01	8081
192.168.1.112	edu-web-02	8081

 

Redis Cluster

Redis cluster built with TWEMPROXY

192.168.1.122	edu-redis-01	6660/6661
192.168.1.123	edu-redis-02	6661
192.168.1.124	edu-redis-03	6661

 

Related commands: (including configuration file address)

 

Need to start on 192.168.1.122, 123, 124 respectively:
SSDB 7770 7771 8880 8881
nohup /usr/local/ssdb/ssdb-server   /usr/local/ssdb-master/ssdb_basic_7770.conf &  
nohup /usr/local/ssdb/ssdb-server   /usr/local/ssdb-master/ssdb_basic_7771.conf &  
nohup /usr/local/ssdb/ssdb-server   /usr/local/ssdb-master/ssdb_desc_8880.conf  &  
nohup /usr/local/ssdb/ssdb-server   /usr/local/ssdb-master/ssdb_desc_8880.conf  &  

REDIS
192.168.1.122：6660 6661
/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis_6660.conf &
/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis_6661.conf &
192.168.1.123 6661
/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis_6661.conf &
192.168.1.124 6661
/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis_6661.conf &

Start Twemproxy
nutcracker.init {start|stop|status|restart|reload|condrestart}
nutcracker -d -c /usr/local/twemproxy/conf/nutcracker.yml -p /usr/local/twemproxy/run/redisproxy.pid -o /usr/local/twemproxy/run/redisproxy.log

 

 

test:

 

redis-cli -h 192.168.1.122 -p 1115

 

2. Configure Tomcat

2.1 Add jar packages and put these 3 jar packages in the lib directory of Tomcat

tomcat-redis-session-manager-1.2-tomcat-7.jar
jedis-2.1.0.jar
commons-pool-1.6.jar

 

2.2 Setting up the Tomcat configuration file

Modify the context.xml file and add it in <context></context>

<Context>

    <!-- Default set of monitored resources -->
    <WatchedResource>WEB-INF/web.xml</WatchedResource>

    <!-- Uncomment this to disable session persistence across Tomcat restarts -->
    <!--
    <Manager pathname="" />
    -->

    <!-- Uncomment this to enable Comet connection tacking (provides events
         on session expiration as well as webapp lifecycle) -->
    <!--
    <Valve className="org.apache.catalina.valves.CometConnectionManagerValve" />
    -->

	<Valve className="com.radiadesign.catalina.session.RedisSessionHandlerValve"/>
	<Manager className="com.radiadesign.catalina.session.RedisSessionManager" database="0" host="192.168.1.122" maxInactiveInterval="60" port="1115"/>
</Context>

 

 Note: I have a problem with the server.xml configuration, and the configuration in <context> was not successful at first, the reason is not checked

 

2.3 Running the test environment

Add the WEB project to the two Tomcats and start them.
Add the following code in the index.jsp of the test1 application
<%
session.setAttribute("shareSession", "redis share Session")
%>
<a href="/test2">test2 index.jsp</a>
in the test2 application Add the following code to index.jsp
<%=session.getAttribute("shareSession")%> (the output is NULL)
to visit Tomcat1 and Tomcat2 respectively, and find that the jsessionid of the browsers on both sides is the same, run key * in the Redis console and print it out is the shared jsessionid .

 

Reference is: Session sharing test based on Redis cache

 

In addition, you can also use memcache, not practice

1. Modify the context.xml file in the conf directory of tomcat:
  <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager" memcachedNodes="n1:localhost:11211 n2:localhost:11212" failoverNodes="n2"   
  requestUriIgnorePattern= ".*\.(png|gif|jpg|css|js)$" sessionBackupAsync="false" sessionBackupTimeout="100" transcoderFactoryClass="de.javakaffee.web.msm.serializer.javolution.JavolutionTranscoderFactory" copyCollectionsForSerialization="false" />;

2. The above is an example of version 1.3. The required jar packages are:
memcached-session-manager-1.3.0.jar
msm-javolution-serializer-1.3.0.jar
javolution-5.4.3.1.jar
memcached- 2.4.2.jar

 

 

 

Four. Based on terracotta server sharing

 

 Reference: http://www.cnblogs.com/interdrp/p/4056525.html to be implemented