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