应用服务器的高可用架构设计主要基于服务无状态这一特性，但实际上，业务总是有状态的，在交易类的电子网站，需要有购物车记录用户的购买信息，用户每次购买请求都是向购物车中增加商品；在社交类网站中，需要记录用户的当前登录状态、最新发布的消息及好友状态等，用户每次刷新页面都需要更新这些信息。
Web应用中将这些多次请求修改使用的上下文对象称作会话（session），单机情况下，session可由部署在服务器上的web容器管理。在使用负载均衡的集群环境中，由于负载均衡服务器可能会将请求分发到集群的任何一台服务器上，所以保证每次请求依然能够获得正确的session比单机时要复杂很多。
集群环境下，session管理主要有一下几种手段。
-
Session复制
Session复制是早期企业应用系统使用较多的一种服务器集群session管理机制。应用服务器开启web容器的session复制功能，在集群中的几台服务器之间同步session对象，使得每台服务器上都保存所有用户的session信息，这样任何一台机器宕机都不会导致session数据的丢失，而服务器使用session时，也只需要在本机获取即可。
这种方案虽然简单，从本机读取session信息很快，但只能用在集群规模比较小的情况下。当集群较大时，集群服务器间需要大量的通信进行session复制，占用服务器和网络的大量资源。而且由于所有用户的session信息在每台服务器上都有备份，在大量用户访问的情况下，会出现服务器内存不够session使用的情况。
而大型网站的核心应用集群就是数千台服务器，同时在线用户可达千万，因此不适应这种方案。
-
Session绑定
Session绑定可以利用负载均衡的源地址Hash算法实现，负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上（也可以根据Cookie信息将同一个用户的请求总是分发到同一台服务器上，当然这时负载均衡服务器必须工作在HTTP协议层上。）这样在整个回话期间用户所有的请求都在同一台服务器上处理，即session绑定在某台特定的服务器上，保证session总能在这台服务器上获取。这种方法又被称作回话粘滞。
但是session绑定的方案显然不符合我们对系统高可用的需求，因为一旦某台服务器宕机，那么该机器上的session也就不复存在了，用户请求切换到其他机器后因为没有session而无法完成业务处理。因此虽然大部分负载均衡服务器都提供源地址负载均衡算法，但很少有网站利用这个算法进行session管理。
-
利用Cookie记录Session
早期的企业应用系统使用C/S(客户端/服务器端)架构，一种管理session的方式是将session记录在客户端，每次请求服务器的时候，将session放在请求中发送给服务器，服务器处理完请求后再将修改过的session响应给客户端。
网站没有客户端，但是可以利用浏览器支持的Cookie记录session。
利用Cookie记录session也有一些缺点，比如受Cookie大小限制，能记录的信息有限；每次请求响应都需要传输Cookie，影响性能；如果用户关闭Cookie，访问就会不正常。但是由于Cookie的简单易用，可用性高，支持应用服务器的线性伸缩，而大部分应用需要记录的session信息又比较小。因此事实上，许多网站都或多多少的使用Cookie记录session。
-
Session服务器
那么有没有可用性高、伸缩性好、性能也不错，对信息大小又没有限制的服务器集群session方案呢？
答案就是session服务器。利用独立部署的session服务器（集群）统一管理session，应用服务器每次读写session时，都访问session服务器。
这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的session服务器，然后针对这两种服务器的不同特性分别设计其架构。
对应有状态的session服务器，一种比较简单的方法是利用分布式缓存、数据库等，在这些产品的基础上进行包装，使其符合session的存储和访问要求。如果业务场景对session管理有比较高的要求，比如利用session服务集成单点登录（SSO）、用户服务等功能，则需要开发专门的session服务管理平台。
本文转自 www19 51CTO博客，原文链接：http://blog.51cto.com/doujh/1738686，如需转载请自行联系原作者
