分布式session的实现方式

谁借莪１个温暖的怀抱￠ 2022-03-20 14:37 142阅读 0赞

**Cookie是什么？** Cookie 是一小段文本信息，伴随着用户请求和页面在 Web 服务器和浏览器之间传递。Cookie 包含每次用户访问站点时 Web 应用程序都可以读取的信息。（**Cookie 会随每次HTTP请求一起被传递服务器端，排除js，css，image等静态文件，这个过程可以从fiddler或者ie自带的网络监控里面分析到，考虑性能的化可以从尽量减少cookie着手）**

![20190213153854496.png][]

我们可以看到在服务器写的cookie，会通过响应头Set-Cookie的方式写入到浏览器。

**Session是什么？ **Session我们可以使用它来方便地在服务端保存一些与会话相关的信息。比如常见的登录信息。

**Session实现原理？ HTTP协议是无状态的，对于一个浏览器发出的多次请求，WEB服务器无法区分 是不是来源于同一个浏览器。**所以服务器为了区分这个过程会通过一个sessionid来区分请求，而这个sessionid是怎么发送给服务端的呢？前面说了cookie会随每次请求发送到服务端，并且cookie相对用户是不可见的，用来保存这个sessionid是最好不过了。

**cookie和session的区别：**

1、session保存在服务器，客户端不知道其中的信息；cookie保存在客户端，服务器能够知道其中的信息。    
2、session中保存的是对象，cookie中保存的是字符串。      
3、session不能区分路径，同一个用户在访问一个网站期间，所有的session在任何一个地方都可以访问到。而cookie中如果设置了路径参数，那么同一个网站中不同路径下的cookie互相是访问不到的。    
4、session需要借助cookie才能正常,如果客户端完全禁止cookie，session将失效。

分布式session方案：

在搭建完集群环境后，不得不考虑的一个问题就是用户访问产生的session如何处理。如果不做任何处理的话，用户将出现频繁登录的现象，比如集群中存在A、B两台[服务器][Link 1]，用户在第一次访问网站时，Nginx通过其负载均衡机制将用户请求转发到A服务器，这时A服务器就会给用户创建一个Session。当用户第二次发送请求时，Nginx将其负载均衡到B服务器，而这时候B服务器并不存在Session，所以就会将用户踢到登录页面。这将大大降低用户体验度，导致用户的流失，这种情况是项目绝不应该出现的。

我们应当对产生的Session进行处理，通过粘性Session，Session复制或Session共享等方式保证用户的体验度。

以下我将说明5种Session处理策略，并分析其优劣性。

**第一种：粘性session**

原理：粘性Session是指将用户锁定到某一个服务器上，比如上面说的例子，用户第一次请求时，负载均衡器将用户的请求转发到了A服务器上，如果负载均衡器设置了粘性Session的话，那么用户以后的每次请求都会转发到A服务器上，相当于把用户和A服务器粘到了一块，这就是粘性Session机制。

优点：简单，不需要对session做任何处理。

缺点：缺乏容错性，如果当前访问的服务器发生故障，用户被转移到第二个服务器上时，他的session信息都将失效。

适用场景：发生故障对客户产生的影响较小；服务器发生故障是低概率事件。

实现方式：以Nginx为例，在upstream模块配置ip\_hash属性即可实现粘性Session。

upstream mycluster{
        #这里添加的是上面启动好的两台Tomcat服务器
        ip_hash;#粘性Session
         server 192.168.22.229:8080 weight=1;
         server 192.168.22.230:8080 weight=1;
    }

**第二种：服务器session复制**

原理：任何一个服务器上的session发生改变（增删改），该节点会把这个 session的所有内容序列化，然后广播给所有其它节点，不管其他服务器需不需要session，以此来保证Session同步。

优点：可容错，各个服务器间session能够实时响应。

缺点：会对网络负荷造成一定压力，如果session量大的话可能会造成网络堵塞，拖慢服务器性能。

实现方式：

① 设置tomcat ，server.xml 开启tomcat集群功能

![这里写图片描述][20160316084831378]

Address:填写本机ip即可，设置端口号，预防端口冲突。

② 在应用里增加信息：通知应用当前处于集群环境中，支持分布式  
在web.xml中添加选项

**第三种：session共享机制**

使用分布式缓存方案比如[memcached][]、redis，但是要求Memcached或Redis必须是集群。

使用Session共享也分两种机制，两种情况如下：

① 粘性session处理方式

原理：不同的 tomcat指定访问不同的主memcached。多个Memcached之间信息是同步的，能主从备份和高可用。用户访问时首先在tomcat中创建session，然后将session复制一份放到它对应的memcahed上。memcache只起备份作用，读写都在tomcat上。当某一个tomcat挂掉后，集群将用户的访问定位到备tomcat上，然后根据cookie中存储的SessionId找session，找不到时，再去相应的memcached上去session，找到之后将其复制到备tomcat上。

![这里写图片描述][20160316085031092]

② 非粘性session处理方式

原理：memcached做主从复制，写入session都往从memcached服务上写，读取都从主memcached读取，tomcat本身不存储session

![这里写图片描述][20160316085142734]

优点：可容错，session实时响应。

实现方式：用开源的msm插件解决tomcat之间的session共享：Memcached\_Session\_Manager（MSM）

a. 复制相关jar包到tomcat/lib 目录下

JAVA memcached客户端：spymemcached.jar
    
    msm项目相关的jar包：
    
    1. 核心包，memcached-session-manager-{version}.jar
    2. Tomcat版本对应的jar包：memcached-session-manager-tc{tomcat-version}-{version}.jar
    
    序列化工具包：可选kryo，javolution,xstream等，不设置时使用jdk默认序列化。

b. 配置Context.xml ，加入处理Session的Manager

粘性模式配置：

![这里写图片描述][20160316085319130]

非粘性配置：

![这里写图片描述][20160316085415800]

**第四种：session持久化到数据库**

原理：就不用多说了吧，拿出一个数据库，专门用来存储session信息。保证session的持久化。

优点：服务器出现问题，session不会丢失

缺点：如果网站的访问量很大，把session存储到数据库中，会对数据库造成很大压力，还需要增加额外的开销维护数据库。

第五种terracotta实现session复制

原理：Terracotta的基本原理是对于集群间共享的数据，当在一个节点发生变化的时候，Terracotta只把变化的部分发送给Terracotta服务器，然后由服务器把它转发给真正需要这个数据的节点。可以看成是对第二种方案的优化。

![这里写图片描述][20160316085627162]  
优点：这样对网络的压力就非常小，各个节点也不必浪费CPU时间和内存进行大量的序列化操作。把这种集群间数据共享的机制应用在session同步上，既避免了对数据库的依赖，又能达到负载均衡和灾难恢复的效果。

小结

以上讲述的就是集群或分布式环境下，session的5种处理策略。其中就应用广泛性而言，第三种方式，也就是基于第三方缓存框架共享session，应用的最为广泛，无论是效率还是扩展性都很好。而Terracotta作为一个JVM级的开源群集框架，不仅提供HTTP Session复制，它还能做分布式缓存，POJO群集，跨越群集的JVM来实现分布式应用程序协调等，也值得学习一下。

[20190213153854496.png]: /images/20220320/5222f2e01da947f79eeda13cc0840858.png
[Link 1]: https://www.baidu.com/s?wd=%E6%9C%8D%E5%8A%A1%E5%99%A8&tn=24004469_oem_dg&rsv_dl=gh_pl_sl_csd
[20160316084831378]: /images/20220320/32692bc1736a4ccdbd388570b6744924.png
[memcached]: https://www.baidu.com/s?wd=memcached&tn=24004469_oem_dg&rsv_dl=gh_pl_sl_csd
[20160316085031092]: /images/20220320/a6d678e009ca4642a4d89802a66f5628.png
[20160316085142734]: /images/20220320/d6822ac6ea3a47b687d44831b1067497.png
[20160316085319130]: /images/20220320/93d4383ca30c4386bd9411ff80bf084b.png
[20160316085415800]: /images/20220320/3eb60ebc06ba4085a787ae86fb802435.png
[20160316085627162]: /images/20220320/e3fac48d4fa2469fa9a5f7e40fe35e87.png