集群下的Session废掉了有木有\解决方案初探

    本文章为抛砖引玉的话题，其中可能有用词不当或概念错误，欢迎各位斧正以及分享知识。

    作Web的人都知道Session（会话）这种东东，这也是一种常用的技术，都知道HTTP是一种无状态的协议，本来是不能保存用户当前会话状态的，可是有了Cookie和以Cookie为基础的Session技术就能够实现保存用户会话（向天才的Hacker们致敬）；如今几乎全部Web动态脚本语言都将Cookie和Session做为基础的功能封装好了，可是在某些环境中，传统的Session（如下简称“会话”）机制貌似废掉了，彻底不能用或者有很大的隐患了。

    如上图是一种简单的均衡负载架构思想，说大型的集群Web系统，一个Web服务是跑在多台服务器上的，多台服务器组成一个集群来进行均衡负载，这种集群架构的优势简单说基本有如下几点：

        1.均衡负载，不会形成某些服务器超负荷而某些服务器空闲。

        2.互为备用机，某些服务器出现问题了，只要不是全部服务器都当掉，服务就仍然能够正常使用，这时候只须要维修有问题的服务器就行了。

        3.无缝升级，进行服务升级的时候能够一台一台地升级和调试，不必中止全部服务，有助于提高用户体验，并不会因服务中止而影响业务收益。

    可是毕竟结构与思想与单机式服务彻底不同，咱们假设以下：

    “负载均衡随机分配的前提下，客户端1访问服务器，均衡负载将这个链接分配给了服务器3，服务建立了一个会话，这个会话显然是存储在服务器3上的，那么客户端1再次访问服务器，可能被负载均衡分配到了服务器2上，此时服务器2上并无先前建立的会话，致使会话丢失。”

    上面这个问题其实很容易解决，如今的负载均衡技术已经很成熟了，能够作到按会话分配服务器，也就是说某客户端在一台服务器上只要建立了一个会话，之后只要这个会话还存活，负载均衡都会把这个客户端的请求自动分配到存有会话的那台服务器上。

    这种解决方案实际上是作了单机式服务向集群式服务的兼容，但仍然没有完全贯彻和发挥集群架构的思想和优点，由于若是有服务器出问题了，那么有问题的服务器上的会话仍是有可能会丢失，用户体验很差。

    对于这种问题，没有任何集群项目经验的我受到了公司架构师的点拨，再结合查阅资料，解决方案基本上有以下几种：

        1.将会话数据加密存储在Cookie中，每次读取解密和加密存储，优势是实现简单，节省服务器存储资源，缺点是加剧消耗服务器计算资源，并且数据存储在客户端上安全性低。

        2.会话同步，将全部Web服务器上的会话互相同步，优势是几乎不用修改代码，缺点是每一台服务器上都保存有当前服务的全部会话，浪费资源，并且对服务器间的流量和响应速度要求高。

        3.使用数据库或相似技术模拟会话机制，将会话存储在特定的数据服务器或数据中心中，优势是可靠性高、节省资源，由于可使用GET/POST方法传送会话ID故不依赖客户端Cookie和会话功能，缺点是须要服务程序专门地有这种功能的设计和实现。

    前两种仍是基于传统Cookie和会话机制的，简单有效，可是若是是大量使用会话的大型企业级服务的话最好要用第3种了，对于禁用Cookie功能的客户端只能用第3种方案（吐槽三星SmartTV的应用框架:P），结构以下图所示：

    通常服务会话对存储资源的要求极低，因此会话服务器能够是一台主要服务器+一台镜像备用服务器，可是若是你须要服务会话数据量很大或用的是MemCache技术的话就可能要考虑集群了。

    那我应该用什么技术来存储会话呢？网上有好多解决方案，我的感受有两种最直接和实用：

        1.使用数据库进行可靠的物理存储，优势是数据可靠，缺点是速度慢。

        2.使用相似MemCache或内存表的技术直接存在内存中，优势是高效率，缺点是服务器当了数据也可能就丢失了，并且内存表有严格的数据大小的限制。

        3.（不要吐槽我不识数额。。。）以上两种的混合方案。

 

    以上只是一些思想，接下来就是实践了，Just do it！2333~~~

    P.S.:很久没写字了，有点罗嗦了。。。

本文章系受著做权法保护,未经著做人赞成,不得盗用；使用或引用本文章内容请注明做者名、原地址：书中叶http://www.cnblogs.com/libook