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