我们知道，http请求是无状态的，但是事实上，业务总是有状态的，在交易类的电子商务网站，需要有购物车记录用户的购买信息，用户每次购买请求都是向购物车中增加商品;在社交类的网站中，需要记录用户的当前登录状态、最新发布的消息及好友状态等，用户每次刷新页面都需要更新这些信息。
一般生产生的软件，出于用户量大的考虑，都是采用负载均衡模式的。用户每次请求可能不在同一服务器处理，那用户的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大小限制，能记录的信息有限;每次请求响应都需要传输Cookie,影响性能；如果用户关闭Cookie,访问就会不正常。
四、Session服务器
那么有没有可用性高、伸缩性好、性能也不错，对信息大小又没有限制的服务器集群Session管理方案呢?答案就是Session服务器。利用独立部署的Session服务器(集群)统一管理 Session,应用服务器每次读写Session时，都访问Session服务器。
