开发者学堂课程【Tomcat 服务器入门详解：Memcached 和 Msm】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/654/detail/10849
Memcached 和 Msm
启动之前先定一个日志
[root@nodex ~]# tail -f /usr/local/tomcat/logs/catalina.out
2node2
[ root@nodex tomcat]# bin/startup.sh
3nodes3
[ root@nodex tomcat]# bin/startup.sh
启动后
finished initialization:
sticky: true
operation timeout: 1000
node ids: [n2]
faiilover node ids: [n1]
storage key prefix: null
locking mode: null (expiration: 5s)
故障的是n2，使用的是n1。查看结果，因为没有人访问，所以一个section都没有。
点击151查看访问的是哪台服务器：
On tomcats
192.168.142.153:8080
SessionlD=49D8F38C46D4731FFC43080FC5812EE6n1.Tomcat2Tue Jan 14 15:18:58 CST 2020
153是Tomcat2产生的，我是Tomcat2，数据放在n1里面。按照之前所说，里面应该是没有数据的，因为没有任何数据可以产生在里面，
('192.168.142.152:11211 (1)'，{ '49D8F38C46D4731FFC43080FC5812BE6-n1.Tomcat2 ' : '[97 b;1578988133 s.]’})
("192.168.142.153:11211 (1)',{ })
N1有，153没有，有个数据'49D8F38C46D4731FFC43080FC5812BE6-n1.Tomcat2 '
关闭152，查看153中是否有数据，
2node2
[ root@nodex tomcat]# systemctl stop Memcached
结果：
[ ( '192.168.142.153:11211 (1)", {})]
------------------------------
( "192.168.142.153:11211 (1)',{ })
on tomcats
192.168.142.153:8080
sessionID = 49D8F38C46D4731FFC43080FC5812EE6-n2, Tomcat2
Tue Jan 14 15:20:55 csT 2020
是tomcat的值，但是值是从n2中来，再次打开发现153中有值了。
2node2
[ root@nodex tomcat]# systemctl start Memcached
On tomcats
192.168.142.152:8080
SessionlD = 49D8F38C46D4731FFC43080FC5812EE6-n2Tomcat1
Tue Jan 14 15:22:05 CST 2020
152中依然有值，来自tomcat2但是存在n2中。
原理实际上就是一个主备的方式,tomcat是一个主要的节点，
关闭两个memcached没有问题，因为section放在tomcat中。
2node2
[ root@nodex tomcat]# systemctl stop Memcached
3node3
[ root@nodex tomcat]# systemctl stop Memcached
重新启动使用python再进行连接，
2node2
[ root@nodex tomcat]# systemctl start Memcached
里面没有东西，只需要多访问几次，主发现备上线了就会往里面写东西，充分证明这是一个备用的，因为tomcat本身有内存。
. \ / .
. x .
./ \ .
使用一段时间后，左侧节点失效，访问右侧节点，发现没有就往左侧再写一个，写的存在m2中，再修改个名字就可以用在t2中，所以最重要的是section id。
8、non-sticky 模式
原理
从msm 1.4.0之后开始支持non-sticky模式。
Tomcat session为中转Session，如果n1为主session，n2为备session。产生的新的Session会发送给主、备memcached，并清除本地Session。
n1下线，n2转正。n1再次上线，n2依然是主Session存储节点。
Tomcat只是一个管理器，作为生成section id的点，以N1、n2为主备，以解决高可用的问题，新产生的主和备会放到memcached中，不保留本地的section，故障转移就是n1下线，n2转正。n1再次上线，n2依然是主Session存储节点，因为故障转移太耗费时间，所以一般是不进行转移，除非再出现问题，再进行转移。
memcached配置
放到$CATALINA_HOME/ conf/context.xm1中
…
sticky="false"前面是主，后面是备,假如前面挂了，前面就变成了备，后面为主，这么一个方式，
sessionBackupAsync="false"
lockingMode="uriPattern: /path1| /path2"
requestUriIgnorePattern=".*l.(ico|pnglgifljpg|cssljs)$”
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
/>
结束修改配置后，
3node3
[ root@nodex tomcat]# vim conf/context .xml
[ root@nodex tomcat]# systemctl start Memcached
2node2
[ root@nodex tomcat]# systemctl start Memcached
运行之后两个都处于清空的状态，什么都没有。
[ root@nodex tomcat]# bin/startup .sh
启动之后查看主和备运行状态。Tomcat都是客户端，连接到这两个上面去，刷新。
On tomcats
192.168.142.153:8080
SessionlD = F31A46E20BOA8B3978275A25ECC30DFB-n2.Tomcat2t
Tue Jan 14 15:33:54 CST 2020
('192.168.142.152:11211 (1)'， 'bak:F31A46E20B0A8B3978275A25ECC30DFB-n2.Tomcat2': '[97 b; 1578990833 s])('192.168.142.153:11211 (1)'，('F31A46E20B0A8B3978275A25ECC30DFB-n2.Tomcat2':'[97 b; 1578990834 s]')
如果n2是主，则n1是备份，如果关闭第二个，就会被迫用第一个，如果应用memached，那么第一个中的section id 不会改变，
3node3
[ root@nodex tomcat]# systemctl stopt Memcached
发现153没有数据，152中有数据，
('192.168.142.152:11211(1)'，{ 'F31A46B20B0A8B3978275A25BCC30DFB-n1.Tomcat2': '[97 b; 1578990916 s]',
' bak:F31A46E20BOA8B3978275A25ECC30DFB-n2.Tomcat2': '[97 b; 1578990833 s]' })
153中没有数据，但是back还在这里，构造了一个为tomcat生成的，但是放在了n1上。
再刷新一次，回到153,
('192.168.142.152:11211(1)'，{ 'F31A46E20B0A8B3978275A25ECC30DFB-n1.Tomcat2' : ' [97 b; 1578990916 s]',
bak:F31A46E20BOA8B3978275A25ECC30DFB-n2.Tomcat2': '[97 b; 1578990833 s]'))
3node3
[ root@nodex tomcat]# systemctl start Memcached
两台都有数据，但是现在访问的是152，152说n1上一直有数据，一直刷新也存在数据，除非再换一台，所以数据有可能不一定在。
换一台，
On tomcats
192.168.142.153:8080
SessionID = A608B7FDE43EEC79293CC3483D9F2514-n1.Tomcat2
Tue Jan 14 15:38:18 CST 2020
主上是n1，就会放置一个备用的memached，放置一个bak,以防止主丢失，就是通过bak查看，tomcat可以作为memached section一个很有用的备份。
Redis配置
下载jedis.jar，放到$CATALINA_HOME/lib/，对应本次安装就是/usr/local/tomcat/lib.
# yum install redis
# vim /etc / redis.conf
bind 0.0.0.e
# systemctl start redis
放到$CATALINA_HOME/conf/context.xm1中
...
sticky="false"
sessionBackupAsync="false"
lockingMode="uriPattern: / path1|/path2"
requestUriIgnorePattern=".*l.(ico|pnglgifljpg|cssljs)$”
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
/>
[ root@nodex tomcat]# vim /etc/redis.conf
[ root@nodex tomcat]# vim conf /context.xml
删掉manger，修改为下面内容。
sticky="false"
sessionBackupAsync="false"
lockingMode="uriPattern: / path1|/path2"
requestUriIgnorePattern=".*l.(ico|pnglgifljpg|cssljs)$”
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
/>
[ root@nodex tomcat]# bin /shutdown.sh
[ root@nodex tomcat]# bin/shutdown.sh
[ root@nodex tomcat]# ss -tanl
[ root@nodex tomcat]# bin/startup.sh
两台都连接到redis.
给大家推荐一个软件：redis desktop manger，不要升级到最新版，它的0.88版本是免费的，可以支持redis3和4的连接。
[ root@nodex tomcat]# systemctl start redis
Redis 默认16个库都在下面，
使用这个登录发现n1、n2没有了，在零号库中以二进制形式进行了存储，就可以认为其被当成了字符串看，可以看到其中有tomcat1，默认使用0号库。只需要按照官方方案进行配置测试。
二、总结
二、总结通过多组实验，使用不同技术实现了session持久机制
1. session绑定，基于IP或session cookie的。其部署简单，尤其基于session黏性的方式，粒度小，对负载均衡影响小。但一旦后端服务器有故障，其上的session丢失。
2. session复制集群，基于tomcat实现多个服务器内共享同步所有sessior此方法可以保证任意一台后端服务器故障，其余各服务器上还都存有全部session，对业务无影响。
但是它基于多播实现心跳，TCP单播实现复制，当设备节点过多，这种复制机制不是很好的解决方案。且并发连接多的时候，单机上的所有session占据的内存空间非常巨大，甚至耗尽内存。（最主要的问题，内存消耗太大，即使带宽够，也有可能忙不过来，内存不足够，所以说节点少了问题不打，但是节点多了就会有很多问题，section值是必须要保存的，所以适合小的集群）
3. session服务器，将所有的session存储到一个共享的内存空间中，使用多个冗余节点保存session，这样做到session存储服务器的高可用，且占据业务服务器内存较小。
是一种比较好的解决session持久的解决方案。（必须要搞出一个主备模型，找不到就去别的节点找，找到后section的信息是一样的，只是有的时候会带有一些信息，之后会发现section id定住了，所以无论是配置slm,无论是什么模式，都能解决业务中的问题，按照官方的配置，至少搞两台，搞两台redis或者memached就可以了，这种应用比较少，只需要解决最后的单节点问题就可以。
以上的方法都有其适用性。生产环境中，应根据实际需要合理选择。
不过以上这些方法都是在内存中实现了session的保持，可以使用数据库或者文件系统，把session数据存储起来，持久化。这样服务器重启后，也可以重新恢复session数据。
不过session数据是有时效性的，是否需要这样做，视情况而定。（大多数都用第三种方法，section是可以在tomca中进行持久化的，但是tomact挂掉之后肯定会调用另外一个，就算持久化，再重新调用也没什么用了，所以要考虑这种方式适合不适合，会见这些section持久化，但是一旦配置多台tomact，就会出现section乱蹦乱跳的问题，解决方案为使用无section机制，但这是另一套处理方案，比较适合互联网这种在一个点上登录，在多个点上都不支持登录的情况，但目前情况中section使用是比较多的）
