`
lovewinner
  • 浏览: 51407 次
  • 性别: Icon_minigender_1
  • 来自: 保定
社区版块
存档分类
最新评论

session共享

 
阅读更多

经过查询资料,解决网站跨服务器之间的Session共享方案大概有以下3种方案

非红色字体为网上的文章摘录:

1. 基于NFSSession共享

NFSNet FileSystem的简称,最早由Sun公司为解决Unix网络主机间的目录共享而研发。

这个方案实现最为简单,无需做过多的二次开发,仅需将共享目录服务器mount到各频道服务器的本地session目录即可缺点是NFS依托于复杂的安全机制和文件系统,因此并发效率不高,尤其对于session这类高并发读写的小文件, 会由于共享目录服务器的io-wait过高,最终拖累前端WEB应用程序的执行效率。

本方法开发成本底,在现阶段对项目数据操读写量尚不明确的情况下,可作为先行试验方法,若此方法不能满足项目需求,可以换别的方案或者在本方案的基础上进行改进。

2. 基于数据库的Session共享

首选当然是大名鼎鼎的Mysql数据库,并且建议使用内存表Heap,提高session操作的读写效率。这个方案的实用性比较强,相信大家普遍在 使用,它的缺点在于session的并发读写能力取决于Mysql数据库的性能,同时需要自己实现session淘汰逻辑,以便定时从数据表中更新、删除 session记录,当并发过高时容易出现表锁,虽然我们可以选择行级锁的表引擎,但不得不否认使用数据库存储Session还是有些杀鸡用牛刀的架势。

此方法开发成本高,而且效率不高,不予考虑。

3. 基于CookieSession共享

这个方案我们可能比较陌生,但它在大型网站中还是比较普遍被使用。原理是将全站用户的Session信息加密、序列化后以Cookie的方式,统一 种植在根域名下(如:.host.com),利用浏览器访问该根域名下的所有二级域名站点时,会传递与之域名对应的所有Cookie内容的特性,从而实现 用户的CookieSession 在多服务间的共享访问。

这个方案的优点无需额外的服务器资源;缺点是由于受http协议头信心长度的限制,仅能够存储小部分的用户信息,同时Cookie化的 Session内容需要进行安全加解密(如:采用DESRSA等进行明文加解密;再由MD5SHA-1等算法进行防伪认证),另外它也会占用一定的带 宽资源,因为浏览器会在请求当前域名下任何资源时将本地Cookie附加在http头中传递到服务器。

这种解决方法的优点是减轻了服务器的压力、节省资源。而且一个session中的两次或多次请求可以在一个群集中的多个服务器上完成

总结,由于整个系统较大,不能局限于web端。用户的Session(只需简单的username,userid,权限,登入统计,用户状态,其余的还是靠数据库服务处理)必定需在coreserver有处理,web应用服务较多,如用户信息服务(注册之类,较多的依靠jsf,离不开httpSession),文件服务,地图服务,没必要在放在同一台服务器上,也没必要将httpSession共享,后2者甚至不需要httpsession,直接使用 coreserversession数据即可。


而对于一个实际项目来说,不能太局限,采取一般解决思路就是选择某一种方案为依托,并汲取其他方案的优点,针对项目实际设计开发出满足要求的方案。手头上的资料比较贫乏,现阶段得出的结论会有所偏差,需继续调研。

  • 大小: 10.2 KB
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics