分布式session处理方案

http://blog.csdn.net/aoxida/article/details/43409151

  1.tomcat自带的方案，session复制，笨重低效，基本上是淘汰的方案。

。

  3.基于redis等nosql的session集中存储，tomcat配置也比较简单。这种最流行，但仍然存在以下问题：（1）redis有单点，并且增加了系统复杂度。(2)用来连接redis的jedis性能不稳定，高并发下很容易挂，这点看到过不少反馈。

  4.纯cookie，不使用session，天然分布式。存在的问题：（1）cookie需要加解密，性能消耗要考虑，而且不能存太多东西，序列化本身消耗也不少。(2)每次请求都会带上cookie，包括JS和CSS等请求，浪费宽带，除非部署了CDN或专用服务器。

  第一种，基于web服务器间的session复制。在web服务器之间进行session复制的方案是当前成熟的方案，很多网站在采用。原理是：在一台web服务器发生session变化的时候，web服务器自动同步复制到另外的web服务器上。就java领域而言，即在调用session.setAttribute()方案的时候会触发session复制。

基于web服务器间的session复制的session管理的缺点是当web服务器增多或者是遇到某些session复制性能不高的web服务器时，多web服务器间的session复制将是很大的性能开销。 

第二种，基于cookie的管理方式。从大型网站的设计原则来看，其中有一条就是减少session的使用，能用cookie的尽量用cookie。 考虑用户登录的场景，在web服务器A收到登录的请求时，将登录的信息以加密cookie的方式存在在客户端。

基于cookie的管理方式的session管理的缺点是，cookie是存在于浏览器端的，虽然经过加密，但是对于某些数据还是有风险的。因此对安全性高的网站不适用。

第三种，基于state server的session管理方式。在.net领域提供一种经常使用的stateserver的session管理的实现方式，即将session数据发送到state server储存，同时将数据持久化到在state server对应的sql server数据库中。

第四种是以memcached为session管理方式。在php领域常用，这是一种非常常见的解决方案，这是一种非常利于扩展的session管理解决方案，因为memcached集群的可扩展性是非常强的。

在分布式集群环境下，session的获取就不能采用request.setSession了。那么如何解决分布式session的问题呢，有以下几个方案：

1.tomcat容器自动同步session。

详见http://www.360doc.com/content/10/0309/14/495229_18116558.shtml

2.其它方案：alibaba b2b采用的cookie的方案，这里面要关心的是信息的安全，如何防止信息的伪造并提交，这个以后可以研究。至于tair的方案，就是淘宝系现在采用的方案，是有通用代表性的方案

web集群时session同步的3种方法[转]

在做了web集群后，你肯定会首先考虑session同步问题，因为通过负载均衡后，同一个IP访问同一个页面会被分配到不同的服务器上，如果session不同步的话，一个登录用户，一会是登录状态，一会又不是登录状态。所以本文就根据这种情况给出三种不同的方法来解决这个问题：

 

一，利用 数据库 同步session

1，用一个低端电脑建个数据库专门存放web服务器的session，或者，把这个专门的数据库建在文件服务器上，用户访问web服务器时，会去这个专门的数据库check一下session的情况，以达到session同步的目的。

2，这种方法是把存放session的表和其他数据库表放在一起，如果 MySQL 也做了集群了话，每个mysql节点都要有这张表，并且这张session表的数据表要实时同步。

说明：用数据库来同步session，会加 大数据 库的负担，数据库本来就是容易产生瓶颈的地方，如果把session还放到数据库里面，无疑是雪上加霜。上面的二种方法，第一点方法较好，把放session的表独立开来，减轻了真正数据库的负担

二，利用cookie同步session

session是存放在服务器端的，cookie是存放在客户端的，怎么实现同步呢？方法很简单，就是把用户访问页面产生的session放到cookie里面，就是以cookie为中转站。你访问web服务器A，产生了session把它放到cookie里面了，你访问被分配到web服务器B，这个时候，web服务器B先判断服务器有没有这个session，如果没有，在去看看客户端的cookie里面有没有这个session，如果也没有，说明session真的不存，如果cookie里面有，就把cookie里面的sessoin同步到web服务器B，这样就可以实现session的同步了。

说明：这种方法实现起来简单，方便，也不会加大数据库的负担，但是如果客户端把cookie禁掉了的话，那么session就无从同步了，这样会给网站带来损失；cookie的安全性不高，虽然它已经加了密，但是还是可以伪造的。

三，利用memcache同步session

memcache可以做分布式，如果没有这功能，他也不能用来做session同步。他可以把web服务器中的内存组合起来，成为一个”内存池”，不管是哪个服务器产生的sessoin都可以放到这个”内存池”中，其他的都可以使用。

优点：以这种方式来同步session，不会加大数据库的负担，并且安全性比用cookie大大的提高，把session放到内存里面，比从文件中读取要快很多。

缺点：memcache把内存分成很多种规格的存储块，有块就有大小，这种方式也就决定了，memcache不能完全利用内存，会产生内存碎片，如果存储块不足，还会产生内存溢出。

四，总结

上面三种方法都是可行的

第一种方法，最影响系统速度的那种，不推荐使用；

第二种方法，效果不错，不过安全隐患一样的存在；

第三种方法，个人觉得第三种方法是最好的，推荐大家使用

 Spring-Session-Redis-Data 存储集群的 Session，只需要配置，不用写一行代码。