Introduction and use of MSM--Memcached_Session_Manager

From gong1208: Introduction and use of MSM--Memcached_Session_Manager

We all know that for some large-scale web2.0 websites, they are generally deployed on multiple application servers in different fault domains during formal deployment. Taking j2ee applications as an example, generally we will Deployed under tomcat, if we deploy 10 tomcat servers, then these 10 tomcats may be deployed on different machines, and then copy the application to these 10 tomcats, and then start all tomcats, generally do this The purpose is to achieve load balancing and avoid single point of failure. In addition, the domestic network environment is also considered to avoid the problem of low access speed caused by cross-network operator access. Of course, don't forget to sit in front of these 10 tomcats. Our reverse proxy server, such as nginx, is another topic. What I mainly talk about today is how to ensure the uniqueness of the session for this distributed tomcat environment (I assume you know what a session is). This is also a problem that I was responsible for solving in a project of Date Company. Of course, this is not a new topic. There have been many solutions before, but in general, the general solution is to write a piece of code or pass Configure the filter of tomcat and put the generated sessions in the same in-memory database. In fact, this is indeed feasible, but I am lazy. I always feel that there should be a more convenient and mature solution for this problem. Yes, that is, the Memcached_Session_Manager that I will introduce immediately, or msm for short, which is an open source solution for solving the problem of session sharing in a distributed tomcat environment.
An introduction
(the following content is translated by the individual according to the effect of the msm official website, the original address: http://code.google.com/p/memcached-session-manager/)

Introduction
MSM--memcached session manager is a highly available Tomcat session sharing solution. In addition to quickly reading session information from the local memory (only for sticky sessions), it can also use memcached to access sessions to achieve high availability.
For non-sticky sessions, memcached stores the session directly.
In addition to memcached, other cache components such as memcachedb, membase, etc. can also be used.
Features
Support Tomcat6, Tomcat7
Support sticky and non-sticky sessions
  No single point of failure
         Can handle tomcat failover
         Can handle memcached failover
         Plug-in session serialization
         allows asynchronous session saving to improve response speed
         Only when the session is modified, it will be Writing sessions back to memcached
         JMX Management & Monitoring
Problems solved by MSM
Suppose you have a Tomcat cluster that uses sticky sessions, how do you deal with the single point of failure problem? In order to cope with more concurrency and availability, you can keep adding Tomcat nodes, but the single point of failure will still be a problem: if you use sticky sessions, when one Tomcat fails, other Tomcats cannot take over the session of the failed Tomcat node.
The idea to solve this problem is to save the sticky session in Memcached at the same time. If a single Tomcat fails, other Tomcats in the cluster can get the session information from Memcached.
     [Note] For non-sticky sessions, MSM V1.4.0 and later versions already support it.
How MSM Works
     [Note] The following discussion is only for sticky sessions
. MSM installed on Tomcat uses native memory to save sessions, just like StandardManager. Additionally, when a request ends, the session is sent back to Memcached for backup. When the next request starts, the local session is available and served directly. After the request ends, the session is sent back to Memcached for backup.
When a Tomcat in the cluster fails, the next request will be routed to other Tomcats. Tomcat responsible for processing this request is not aware of Session information. At this point it will look up the Session from Memcached, update the Session and save it in the local content. At the end of the request, the session is modified and sent back to Memcached for backup.


.MSM handles Tomcat failover sequence diagram
What else?
The above is to handle Tomcat failover, how does MSM handle Memcached failover?
If a Memcached fails, the session in the current Memcached will be transferred to other Memcached nodes, and at the same time, the JSESSIONID will be modified and sent back to the browser.
If you use sticky sessions, you should ensure that the JSESSIONID generated by the loadbalancer configuration does not have any suffix.
Format of SESSIONID
MSM knows the list of Memcached nodes, these node identifiers will be stored in SESSIONID, the SESSIONID value is similar: 602F7397FBE4D9932E59A9D0E52FE178-n1 [where n1 is the Memcached node identifier]

Second installation

Reference website: http://code.google.com/p/memcached-session -manager/wiki/SetupAndConfiguration

environment

1. Linux environment
2. Tomcat7.X (3 units), to start three Tomcats on the same machine, you need to modify the three ports in conf/server.xml: 8080, 8005, 8009
3. MemBase (1 unit), memcached can also be used, the usage method is the same, but it is different when the java client connects. 4. The jar package prepared by
nginx Note: Different tomcat versions (tomcat6, tomcat7) require different packages, and you need to download the corresponding package for the tomcat version. 1. This is the latest stable version 1.6.1, serialization method Kryo is used. Note that the version requirements are basically the same as the msm version. It is recommended to use the latest stable version, as follows. The serialization method is optional. kryo serialization configuration msm 2. This is the serialization method used by javalution. All required packages javalution serialization configuration msm is recommended to use kryo serialization method, which is more efficient. configure











1. Copy all the packages mentioned above to the lib of tomcat (all three tomcats are required)
        2. Modify the context.xml file or server.xml file in the conf directory of each tomcat, and add any of the following paragraphs to it Code (Note: When using multiple tomcats, be sure to use non-sticky mode):
A: Use the default sticky session, kryo serialization method, memcached cache

Java code Collection code
<Context> 
  ... 
  <Manager className=" de.javakaffee.web.msm.MemcachedBackupSessionManager" 
    memcachedNodes="n1:host1.yourdomain.com:11211,n2:host2.yourdomain.com:11211" 
    failoverNodes="n1" 
    requestUriIgnorePattern=".*\.(ico|png| gif|jpg|css|js)$" 
    transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory" 
    /> 
</Context> 

B: Use non-sticky session
Java code Favorite code
<Context> 
 
  ... 
 
  <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager" 
memcachedNodes="n1:host1.yourdomain.com:11211,n2:host2.yourdomain.com:11211" 
    sticky="false" 
    sessionBackupAsync="false" 
    lockingMode="uriPattern:/path1|/path2" 
    requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$" 
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory" 
    /> 
 
</Context> 
C：使用membase
Java代码  收藏代码
<Context> 
 
  ... 
 
  <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager" 
    memcachedNodes="http://host1.yourdomain.com:8091/pools" 
After the configuration is complete, start tomcat separately. A normal startup indicates that the msm configuration is successful. 3. Finally attach the nginx configuration:







 











Modify the configuration file nginx\conf\nginx.conf
1. Find the content server {
Add the following content to it:

Java code Favorite code
upstream 10.6.53.120 { 
ip_hash; ----#ip_hash strategy forwards all requests from the same IP to the same application server 
server 10.6.53.120:8080;---------my tomcat port number 
server 10.6.53.120:7080; 
server 10.6.53.120:6080; 
}<span>(</span><span style="">This is the server website used for load switching</span><span>IP)</span> 
2. Find the
Java code Collection code
location / { 
root html; 
index index.html index.htm; 
} 
put the content Change as follows:
Java code favorite code
location / { 
proxy_pass http://10.6.53.120 
proxy_redirect default; 
proxy_connect_timeout 10; added by me (the timeout time for connecting to the proxy server, it must be noted that the timeout time cannot exceed 10 seconds. When a server fails, it will be forwarded to another server after 10 seconds) 
}  
3. Find the
Java code Favorite code
server { 
listen 80; 
server_name localhost;  Change
the content to the following:
Java code Favorite code
server { 
listen 80; 
server_name 10.6.53.120; 
(this is to monitor the request to access the domain name bound to port 80 of the server)
to all here The configuration has been completed, now prepare a simple web project and deploy it to three tomcats respectively. Start memcached (membase), start three tomcats, start nginx, and then enter the url address in the address bar to see if it can be accessed successfully. Shut down one of the tomcats to see if they can still be accessed normally. If so, it means that the configuration of nginx is successful.

Three Principles
MSM (memcached-session-manager) supports tomcat6 and tomcat7, and uses Value (Tomcat valve) to track Request. When the Request request arrives, the session is loaded from memcached. When the Request request ends, the tomcat session is updated to memcached to achieve the purpose of session sharing, and supports sticky and non-sticky modes. It should be noted that jvmroute parameters need to be configured when using sticky mode. The configuration method is as follows:
configure $CATALINA_HOME/conf/server.xml
Java code collection code
<Engine name="Catalina"defaultHost="localhost"jvmRoute="tomcat2"> 
   Note that each The jvmroute parameters of the tomcat cannot be the same as the
Sticky mode: the tomcat session is the main session, and the memcached is the backup session. When the Request request arrives, load the standby session from memcached to tomcat (only when the tomcat jvmroute changes, otherwise directly take the tomcat session); when the Request request ends, update the tomcat session to memcached to achieve the purpose of master-slave synchronization. The following is a flow chart of the response in sticky mode (image source network):
sticky mode

Non-Sticky mode: the tomcat session is the relay session, memcached1 is the primary session, and memcached 2 is the backup session. When the Request request comes, load the standby session from memcached 2 to tomcat, (when there is still no session in the container, load the main session from memcached1 to tomcat, in this case, there is only one memcached node, or there is an error in memcached1), when the Request request ends , update the tomcat session to the primary memcached1 and backup memcached2, and clear the tomcat session. In order to achieve the purpose of master-slave synchronization, the following is the response flow chart of non-sticky mode: (picture source network).

non-sticky

http://www.iteye.com/topic/1125301