[转]分布式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集群功能

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上。

② 非粘性session处理方式

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

优点:可容错,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

粘性模式配置:

非粘性配置:

第四种:session持久化到数据库

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

优点:服务器出现问题,session不会丢失

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

第五种terracotta实现session复制

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


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

小结

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

---------------------
作者:老虎死了还有狼
来源:CNBLOGS
原文:https://www.cnblogs.com/daofaziran/p/10933221.html
版权声明:本文为作者原创文章,转载请附上博文链接!
内容解析By:CSDN,CNBLOG博客文章一键转载插件

原文地址:https://www.cnblogs.com/admans/p/11647240.html

时间: 2024-10-20 16:48:30

[转]分布式session的几种实现方式的相关文章

关于分布式Session 的几种实现方式

分布式Session的几种实现方式 1.基于数据库的Session共享 2.基于NFS共享文件系统 3.基于memcached 的session,如何保证 memcached 本身的高可用性? 4. 基于resin/tomcat web容器本身的session复制机制 5. 基于TT/Redis 或 jbosscache 进行 session 共享. 6. 基于cookie 进行session共享 介绍下常用的分布式Session 实现 1. Session Replication 方式管理 (

分布式session的几种实现方式

1.基于数据库的session共享 2.基于NFS共享文件系统 3.基于memcached 的session,怎么保证session的高可用 4.基于resin/tomcat web容器本身的session复制机制 5.基于TT/Redis 或 jbosscache 进行 session 共享. 6.基于cookie 进行session共享 <1.> Session Replication 方式管理 (即session复制)         简介:将一台机器上的Session数据广播复制到集群

分布式锁的几种实现方式

目前几乎很多大型网站及应用都是分布式部署的,分布式场景中的数据一致性问题一直是一个比较重要的话题.分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性(Consistency).可用性(Availability)和分区容错性(Partition tolerance),最多只能同时满足两项.”所以,很多系统在设计之初就要对这三者做出取舍.在互联网领域的绝大多数的场景中,都需要牺牲强一致性来换取系统的高可用性,系统往往只需要保证“最终一致性”,只要这个最终时间是在用户可以接受的范围内即

分布式锁的三种实现方式

分布式锁三种实现方式: 1. 基于数据库实现分布式锁: 2. 基于缓存(Redis等)实现分布式锁: 3. 基于Zookeeper实现分布式锁: 一, 基于数据库实现分布式锁 1. 悲观锁 利用select … where … for update 排他锁 注意: 其他附加功能与实现一基本一致,这里需要注意的是“where name=lock ”,name字段必须要走索引,否则会锁表.有些情况下,比如表不大,mysql优化器会不走这个索引,导致锁表问题. 2. 乐观锁 所谓乐观锁与前边最大区别在

分布式锁的三种实现方式及其比较(一)

1 实现方式 分布式锁的实现,目前比较常用的有以下几种方案: 基于Zookeeper实现实现分布式锁 基于缓存(如redis等)分布式锁 基于数据库实现分布式锁 2 基于Zookeeper实现实现分布式锁 实现原理是: 每个客户端对某个方法加锁时,在zookeeper上的与该方法对应的指定节点的目录下,生成一个唯一的瞬时有序节点. 判断是否获取锁的方式很简单,只需要判断有序节点中序号最小的一个. 当释放锁的时候,只需将这个瞬时节点删除即可 锁的释放:使用Zookeeper可以有效的解决锁无法释放

分布式锁的几种使用方式(redis、zookeeper、数据库)

Q:一个业务服务器,一个数据库,操作:查询用户当前余额,扣除当前余额的3%作为手续费synchronizedlockdb lockQ:两个业务服务器,一个数据库,操作:查询用户当前余额,扣除当前余额的3%作为手续费分布式锁我们需要怎么样的分布式锁?可以保证在分布式部署的应用集群中,同一个方法在同一时间只能被一台机器上的一个线程执行. 这把锁要是一把可重入锁(避免死锁) 这把锁最好是一把阻塞锁(根据业务需求考虑要不要这条) 这把锁最好是一把公平锁(根据业务需求考虑要不要这条) 有高可用的获取锁和释

第四节:框架前期准备篇之进程外Session的两种配置方式

一. 基本介绍 1. 背景:Asp.Net默认的Session机制是进程内,存储在服务器端内存中,有这么几个缺点: ①:既然存在内存中,空间有限,不能存储大数据量信息,数据量多的话Session会被挤爆. ②:IIS只要一重启,Session就会丢失,哪怕就是改一下配置文件,IIS也会重启,此时如果客户端有用户通过浏览器正在访问该网站,如果用到Session,原Session是丢失的了,就会报“未将对象引用设置到对象的实例”类似的错误. ③:Session是依赖Cookie来保存SessionI

Hibernate(八)--session的两种获取方式

openSession getCurrentSession Hibernate有两种方式获得session,分别是: openSession和getCurrentSession他们的区别在于1. 获取的是否是同一个session对象 openSession每次都会得到一个新的Session对象 getCurrentSession在同一个线程中,每次都是获取相同的Session对象,但是在不同的线程中获取的是不同的Session对象 SessionFactory factory=new Confi

Session的两种实现方式

一.通过session实现 sessionId是通过浏览器的cookie工作的,当客户端浏览器中禁止 Cookie,Servlet 容器无法从客户端浏览器中取得作为 Cookie 的 Session ID,也就无法跟踪客户状态. 服务器端把cookie存放在浏览器端,当在发送请求到服务器端时,将浏览器端存储的cookie值作为http请求头cookie属性的值传送给服务器端,来维持身份. 二.通过URL重写实现 HttpServletResponse 接口提供了重写 URL 的方法:public