Working principle of msm ( reproduced )

MSM working principle: a) Working principle in Sticky Session mode: The
local Tomcat session is the main session, and the session in Memcached is the standby session. When the Request request arrives, load the standby session from memcached to tomcat (only when the tomcat jvmroute changes, otherwise take the Tomcat Session directly); when the request ends, update the Tomcat Session to memcached to achieve the purpose of synchronization between the main and standby. The MSM installed on Tomcat uses the local memory to save the Session. After a request is executed, if the corresponding Session does not exist locally (that is, the first request of a user), copy the Session to Memcached; When the next request for the Session arrives, Tomcat's local Session will be used. After the request is processed, the changes in the Session will be updated to Memcached synchronously to ensure that the data is consistent. When a Tomcat in the cluster hangs down, the next request will be routed to other Tomcats. Tomcat, which is responsible for processing this request, does not know the Session information, so it searches for the Session from Memcached, updates the Session and saves it to the machine. After the request ends, the Session is modified and sent back to Memcached for backup.

b)
The working principle of Non-sticky Session (non-sticky) mode (remember: multiple tomcat clusters or multiple tomcat instances need to select Non-Sticky mode, ie sticky="false"):
Tomcat local session is a transit Session, Memcached1 is the main session, Memcached2 is the standby session. When the Request request comes, load the standby session from Memcached2 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 when there is an error in Memcached1), when the request ends, Update the Tomcat Session to the main Memcached1 and standby memcached2, and clear the Tomcat Session. In order to achieve the purpose of main and standby synchronization. When multiple tomcat clusters, you need to select the Non-Sticky mode, that is, sticky="false"

1) Host allocation

Host	Features
192.168.199.155	tomcat和memcached
192.168.199.157	tomcat和memcached

2) Use yum to install tomcat and memcached

yum install -y tomcat.noarch tomcat-admin-webapps.noarch  tomcat-docs-webapp.noarch    tomcat-webapps.noarch      memcached

3) Prepare the context directory for the two tomcats, where the two hosts operate in the same way

 <Context path="/myapp"  docBase="/webapps/myapp" reloadable="">
         
       </Context>

4) Create context web content


157主机上
[root@ydong ~]# cat /webapps/myapp/index.jsp 
<html>
    <body bgcolor="green">     
    <center>    
    <%=  request.getSession().getId()  %>    
    <h1>192.168.199.157</h1>
    <h1>port:8080</h1>
    <h1>this is Tomcat-node1 ! </h1> 
    </center>
    </body>
</html>
 
<%@ page contentType="text/html;charset=UTF-8" isELIgnored="false"%>
SessionID:<%=session.getId()%><BR>
SessionIP:<%=request.getServerName()%> <BR>
SessionPort:<%=request.getServerPort()%>
<%     out.println("This is Tomcat server 157 !");     %>



155主机上
[root@ydong tomcat]# cat /webapps/myapp/index.jsp 
<html>
    <body bgcolor="green">     
    <center>    
    <%=  request.getSession().getId()  %>    
    <h1>192.168.199.155</h1>
    <h1>port:8080</h1>
    <h1>this is Tomcat-node2! </h1> 
    </center>
    </body>
</html>
 
<%@ page contentType="text/html;charset=UTF-8" isELIgnored="false"%>
SessionID:<%=session.getId()%><BR>
SessionIP:<%=request.getServerName()%> <BR>
SessionPort:<%=request.getServerPort()%>
<%     out.println("This is Tomcat server 157 !");     %>

5) Start two memcached. Here started directly without memcached modify the properties and to be in /etc/sysconfig/memcachedtheir own definition.

systemctl start memcached

6) modify tomcatthe server.xmlfile, add the following in the middle of context. Here is the stick session method. The two hosts are the same

  <Context path="/myapp"  docBase="/webapps/myapp" reloadable="">
            <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
             memcachedNodes="n1:192.168.199.155:11211,n2:192.168.199.157:11211"         
             sticky="true"
             failoverNodes="n2"                                           
             requestUriIgnorePattern=".*\.(png|gif|jpg|css|js|swf|flv)$"
             transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
             copyCollectionsForSerialization="true"
    />
       </Context>

7) Pass in the required jar package, ignore apache-tomcat-9.0.40 Insert picture description here
8) Restart tomcat, and observe whether the log shows a successful startup prompt

十二月 09, 2020 8:16:50 下午 de.javakaffee.web.msm.MemcachedSessionService startInternal
信息: --------
-  finished initialization:
- sticky: true
- operation timeout: 1000
- node ids: [n1]
- failover node ids: [n2]
- storage key prefix: null
- locking mode: null (expiration: 5s)

9) Perform nginx reverse generation, here only simple reverse generation, if you need to add options, you can refer to here

10) Visiting nginx
Insert picture description here

can find that the content here will change, but the session will not change, which proves that it has been successful

PS

If you use nginx to access and find that the session has been changing, and the tomcat log has shown that msm has started successfully, it is a problem of jar package compatibility, and the jar package version is critical. The above jar package only tested the tc7 version installed by yum.

tomcat uses memcached to implement session storage

tc7 version of msm

Working principle of msm ( reproduced )

PS

Guess you like