Session一致性

什么是session

我们都知道，http协议是无状态协议，session会话的出现是对这个无状态做一个补充。它是以键值对存储在服务器里，cookie从客户端返回服务器是会带着session的ID，一般会将用户的基本信息缓存在session中

为什么存在session一致性问题

Web1.0的时代,数据访问量很有限，用的高性能的单节点服务器可以解决大部分问题

在Web2.0时代，由于用户访问量大幅度提升，同时产生了大量的用户数据，所以我们采用分布式架构，我们使用ngnix反向代理服务器,把访问量均衡分配到各个服务器上，
可能会出现这样的问题，当用户第一次登录时，如果访问的是tomcat1，如果按照以往的方式，将用户基本信息缓存在session中时，session对象是保存在tomcat的JVM中。当用户后续再次请求访问其他功能时，如果此时通过nginx将请求分流到tomcat2，将无法从当前tomcat的JVM中获取到用户的基本信息。也就是出现了session不一致的情况

如何解决session一致性问题

方案一、存在Cookie中
限制
① cookie有长度限制，这也就会限制session数据的长度
② 安全性，cookie的数据保存在客户端，这就存在安全性的问题，我们需要对写入cookie的session数据做加密处理
③ 带宽消耗， 客户端每次都要带着session过来，会消耗一定网络资源
④ 性能影响，每次http请求和响应都带有session数据，对web服务器来说，在同样的处理情况下，响应的结果输出越少，支持的并发请求就会越多。

方案二、session会话粘连
在web服务器变成多台后，如果我们可以保证同一个会话请求都能在同一个web服务器上处理，那么对于这个会话个体来说，和单机的情况是一样的。这就需要负载均衡器能够根据每次请求的会话标识来进行请求转发。
限制
① 如果有一台web服务器宕机或重启，那么这台机器上的会话数据会丢失
② 负载均衡器变成了一个有状态的结点，要保存会话到具体web服务器的映射，要消耗一定的内存。

方案三、Session复制
此种方案会导致每个服务器之间必须将Session广播到集群内的每个节点，Session数据会冗余，节点越多浪费越大,存在广播风暴问题.，适用于机器较少。网络流量较少的情况下
限制
① 只要session数据有变化，就需要将数据同步到其他机器上，会带来一定的网络带宽开销
② 每台web服务器都要保存所有的session数据，如果整个集群session数很多的话，对内存资源消耗较大。

方案四、存在Redis中
目前来看，此种方案是最好的。将Session数据存在内存中，每台服务器都从内存中读取数据,速度快，结构还相对简单.
把session数据集中存储起来，然后不同的web服务器从相同的地方来获取session，存储session数据的方式可以为redis，也可以使用其他分布式存储系统。
限制：
① 获取session存在延时和不稳定性，不过我们的通信基本在内网，问题不大。
② 如果存储session的机器或集群发生问题，就会影响到应用。
当集群规模较大时，session数较多时，该方案可以考虑。