集群/分布式环境下session处理策略

集群是个物理形态，分布式是个工作方式。

• 分布式：一个业务分拆多个子业务，部署在不同的服务器上
• 集群：同一个业务，部署在多个服务器上

为什么要处理session？

这个问题想必大多数朋友都知道，在搭建完集群或者分布式环境之后，如果不做任何处理的话，网站将频繁的出现用户未登录的现象。比如：集群中有A、B两台服务器，用户第一次访问网站时，Nginx将用户请求分发到A服务器，这时A服务器给用户创建了一个Session，当用户第二次访问网站时，假设Nginx将用户请求分发到了B服务器上，而这时B服务器并不存在用户的Session，所以就会出现用户未登录的情况，这对用户来说是不可忍受的。
所以我们在搭建集群/分布式环境之后，必须考虑的一个问题就是用户访问产生的session如何处理，即session的共享机制

解决方案

我们将处理Session的方式大致分为三种：

Session保持（也有人叫黏性Session）、

Session复制。

Session共享。

Session保持（或者叫黏性Session）

Session保持（会话保持）就是将用户锁定到某一个服务器上。比如上面说的例子，用户第一次请求时，负载均衡器（Nginx）将用户的请求分发到了A服务器上，如果负载均衡器（Nginx）设置了Session保持的话，那么用户以后的每次请求都会分发到A服务器上，相当于把用户和A服务器粘到了一块，这就是Session保持的原理。Session保持方案在所有的负载均衡器都有对应的实现。而且这是在负载均衡这一层就可以解决Session问题。

优点：非常简单，不需要对session做任何处理。

缺点：1、负责不均衡了：由于使用了Session保持，很显然就无法保证负载的均衡。

缺乏容错性：如果后端某台服务器宕机，那么这台服务器的Session丢失，被分配到这台服务请求的用户还是需要重新登录，所以没有彻底的解决问题。

实现方式：以Nginx为例，在upstream模块配置ip_hash属性即可实现粘性Session

容错性，是指软件检测应用程序所运行的软件或硬件中发生的错误并从错误中恢复的能力，通常可以从系统的可靠性、可用性、可测性等几个方面来衡量。

Session复制

针对Session保持的容错性缺点，我们可以在所有服务器上都保存一份用户的Session信息。这种将每个服务器中的Session信息复制到其它服务器上的处理办法就称为会话复制。当任何一台服务器上的session发生改变时，该节点会把session的所有内容序列化，然后广播给所有其它节点，不管其他服务器需不需要session，以此来保证Session同步。

优点：可容错，各个服务器间的Session能够实时响应。

缺点：将session广播同步给成员，会对网络负荷造成一定压力

实现方式：tomcat本身已支持该功能

tomcat的会话复制分为两种：

全局复制(DeltaManager)：复制会话中的变更信息到集群中的所有其他节点。

非全局复制（BackupManager）：它会把Session复制给一个指定的备份节点。

Session共享

Spring session+Redis(Cluster)保证Session性能和高可用。