集群的session共享

集群的session共享

1.背景
对于负载均衡集群来讲，当用户的请求到达RS1上进行了某些操作，如果再次请求时到了RS2上，那么刚刚的操作结果可能会不会出现(如淘宝的购物车)，因为session是在服务器端保存的，如果用户跳转到其他服务器的话session就会丢失，一般情况下session不可跨服务器而存在，保证用户请求的一致性，于是就有了分布式系统的session共享问题；

2.session共享实现方案
session共享有多种解决方法，常用的有四种：客户端Cookie保存、服务器间Session同步、使用集群管理Session、把Session持久化到数据库。

2.1  客户端cookie保存
把session加密后存在cookie中,每次session信息被写在客服端,然后经浏览器再次提交到服务器.即使两次请求在集群中的两台服务器上完成,也可以到达session共享。

原理：如web集群，将全站用户的Session信息加密、序列化后以Cookie的方式，统一种植在根域名下，利用浏览器访问该根域名下的所有二级域名站点时，会传递与之域名对应的所有Cookie内容的特性，从而实现用户的Cookie化Session在多服务间的共享访问。

优点：
(1)session信息不用存放在服务器端，大大减轻了服务器的压力；
(2)一个session中的两次或多次请求可以在一个集群中的多个服务器上完成，可以避免单点故障；
缺点：
(1)传递cookie时，http信息头的长度限制使我们只能够在cookie中存入一部分用户信息；
(2)需要额外地做session信息加密的工作；
(3)如果采用这种方式，每次访问网站二级域名时都会在http信息头中带有这些以cookie形式存储的session信息，会占用一定的带宽；
(4)由于这种方式是在客户端进行信息存储，用户完全可以禁用cookie或删除cookie，不是很可靠；

2.2  服务器间Session同步
使用主-从服务器的架构模式，当用户在主服务器上登录后，通过脚本或者守护进程的方式，将session信息传递到各个从服务器中，这样，用户访问其它的从服务器时，就可以读到session信息。
缺点：
(1)速度慢、不稳定等;
(2)如果session信息传递是主->从单向的，会有一些风险，比如主服务器down了，其它服务器无法获得session信息；

2.3  使用集群统一管理Session
提供一个群集保存session共享信息.其他应用统统把自己的session信息存放到session集群服务器组。当应用系统需要session信息的时候直接到session群集服务器上读取。

目前大多都是使用Memcache来对Session进行存储,以Memcache来实现Session共享的方式目前比较流行的有两种实现方案:
2.3.1  使用Filter方式
使用过滤器的方式重新对httpRequest对象进行了包装，并加入memcached客户端,此方式的优点是：使用简单，把过滤器配置进去即可，另外比较灵活，因为它是在客户端实现的，配置比较灵活,而且服务器无关，你可以在任何支持servlet的容器上部署

2.3.2  memcached-session-manager（MSM）
memcached-session-manager俗称MSM，是一个用于解决分布式tomcat环境下session共享的问题的开源解决方案。它的实现原理为以tomcat插件的方式部署在服务器，修改了servlet容器代码中的session相关代码，使其连接memcached，在memcached中创建和更新session.

MSM(memcached-session-manager) 利用 Value（Tomcat 阀）对Request进行跟踪。Request请求到来时，从memcached加载session，Request请求结束时，将tomcat session更新至memcached，以达到session共享之目的.支持sticky和non-sticky 模式。

MSM拥有如下特性：
(1)支持Tomcat6、Tomcat7和Tomcat8;
(2)支持黏性、非黏性Session;
(3)可处理tomcat故障转移;
(4)可处理memcached故障转移;
(5)插件式session序列化;
(6)允许异步保存session，以提升响应速度;
(7)只有当session有修改时，才会将session写回memcached;
(8)JMX管理&监控;
关于MSM可参考：

2.4 把Session持久化到数据库
将session信息存入数据库中，其它应用可以从数据库中查出session信息。

利用数据库共享session的方案有一定的实用性，但也有如下缺点：首先session的并发读写在数据库中完成，对mysql的性能要求比较高；其次，我们需要额外地实现session淘汰逻辑代码，即定时从数据库表中更新和删除session信息，这增加了工作量;

附：《淘宝的无状态共享架构》
俗话说，一个系统的伸缩性的好坏取决于应用的状态如何管理。为什么这么说呢？咱们试想一下，假如我们在session中保存了

大量与客户端的状态信息的话，那么当保存状态信息的server宕机的时候，我们怎么办？通常来说，我们都是通过集群来解决这个问题，而通常

所说的集群，不仅有负载均衡，更重要的是要有失效恢复failover,比如tomcat采用的集群节点广播复制，jboss采用的配对复制等session状态复制

策略，但是集群中的状态恢复也有其缺点，那就是严重影响了系统的伸缩性，系统不能通过增加更多的机器来达到良好的水平伸缩，因为集群节

点间session的通信会随着节点的增多而开销增大，因此要想做到应用本身的伸缩性，我们需要保证应用的无状态性，这样集群中的各个节点来说

都是相同的，从而是的系统更好的 水平伸缩。
   
OK，上面说了无状态的重要性，那么具体如何实现无状态呢？此时一个session框架就会发挥作用了。幸运的是淘宝已经具有了此类框架。淘宝

的session框架采用的是client  cookie实现，主要将状态保存到了cookie里面，这样就使得应用节点本身不需要保存任何状态信息，这样在系统

用户变多的时候，就可以通过增加更多的应用节点来达到水平扩展的目的.但是采用客户端cookie的方式来保存状态也会遇到限制，比如每个

cookie一般不能超过4K的大小，同时很多浏览器都限制一个站点最多保存20个cookie.淘宝cookie框架采用的是“多值cookie”，就是一个组合键对

应多个cookie的值，这样不仅可以防止cookie数量超过20，同时还节省了cookie存储有效信息的空间，因为默认每个cookie都会有大约50个字节

的元信息来描述cookie。

参考文章：
集群之session共享
http://blog.sina.com.cn/s/blog_60fcb5a10100zmk0.html

Session共享实现方案调研
http://chenzhou123520.iteye.com/blog/1647186