一样平常生产生的软件，出于用户量大的考虑，都是采取负载均衡模式的。
用户每次要求可能不在同一做事器处理，那用户的session状态是怎么保持同步的了？有如下几中办法：

一、Session复制

Session复制是早期企业运用系统利用较多的一种做事器集群Session管理机制。
运用做事器开启Web容器的Session复制功能，在集群中的几台做事器之间同步Session工具，使得每台做事器上都保存所有用户的Session 信息，这样任何一台机器宕机都不会导致Session数据的丢失,而做事器利用Session 时，也只须要在本机获取即可。
。

phpsession不同步HTTP要求是无状况的那么负载平衡模式下session是若何同步的 React

这种方案虽然大略，从本机读取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做事器。