分布式Session管理

分布式的Session管理：

 参考博文：  http://chenzhou123520.iteye.com/blog/1647186

 推荐博文 ： http://blog.csdn.net/jacktan/article/details/6112806(基于zooKeeper的分布式session管理)

 

  是什么？

    就是在服务器端，不是只有一个服务器来处理你的请求，而是通过一个服务器集群；

    这样你可能这会在A服务器，等下一个请求又跳转到B服务器 ，如果session只是单独存在于

    A服务器中，那么第二次访问不就丢失前一次的数据了吗？所以，怎么在一个服务器集群的环境中

    保证session的同步 ，这就是分布式session管理要解决的问题。

 

  解决的问题？

       Session ID的共享 和 session数据的复制 ： 当在服务器A中修改了Session 的数据，我们必须通过某种机制告知其他服务器！

      Session的失效 ： 因为你无法保证分布式系统中时钟的一致性，中间可能相差几毫秒，几十毫秒，因为，你在服务器A中创建或更新了Session

      然后，你要又通知服务器B创建或更新，这中间明显是存在时差的！所以，可能你在服务器A中，session失效了，在服务器B中，session却仍然有效！

    

  

  怎么做？

     1. 客户端cookies保存：

           就是session信息不在服务端保存，每次请求都把session信息存入cookies , 这样下次请求，你就带着你的session信息到服务器了。

           存在问题： cookies长度限制, 必须对session数据加密处理 ，而且，客户端可能禁用cookies 。

     2. 服务器间session同步：

            这种方法，就是在每个服务间都保存了session数据；比如，我在A服务器登录，那么同样的，session数据就会copy到B服务器

            存在问题 ： session数据是从A到B 的， 如果A 宕机 ， 那么数据就会丢失，B中存的可能是过去的数据！服务器间耦合度太高，对于一个小型的集群还好，

            如果是一个超大型的集群，那么每一次的session修改或创建都要广播其他的服务器，可想而知，这是一件多么麻烦而且低效的事！

      3. 通过集群管理Session：

           这种方法，就是把session抽取出来，交给另一个专门的容器管理！这个容器是一个集群

            memcached-session-manager：

   他的特性：

支持 sticky sessions 和 non-ticky sessions 模式。
没有单点故障。
能处理 tomcat 故障转移
能处理 memcache 故障转移
pluggable session serialization
允许异步存储 session，提高响应速度
sessions 只有真正被修改时，才会发给 memcache

 

 

Sticky Sessions：粘性会话。即同一个会话中的请求必须被转发到同一个节点上，除非该节点宕机才转发到故障转移节点。一个节点宕机，所存储的 Sessions 完全丢失。通俗的话就是，将用户“粘”在某一个服务器节点上。
Non-Sticky Sessions：非粘性会话。每一次请求都可能转发到不同节点。
Replicated Sessions：把一个节点上的 Sessions 复制到集群的其他节点上，防止数据丢失，允许失效无缝转移。如node 0复制到node 5，node 1复制到node 6，以此类推。多数应用服务器（如 Tomcat ）都支持会话复制机制。

 

            

           

       

           

   4. 数据持久化到数据库

       每次都把session数据存入数据库，下次请求的时候，又从数据中，取出数据；

      存在问题：明显，涉及数据库的操作，效率低！