session一致性

单机模式

浏览器第一次访问服务器的时候，服务器会建立一个session并返回给客户端。

浏览器第二次访问session的时候，会携带session到服务器，服务器会判断这个session是否存在，若是不存在，则从新建立一个session。

在单机模式中，只要浏览器不重启，在过时时间内，均可以保持会话。

集群模式

此时浏览器可能访问服务器A，也可能访问服务器B，若是先访问了A，那session是保存在A中的，此时再访问B，session找不到，就要从新登陆了。

session粘滞

此时可能会想，经过session的粘滞，让浏览器固定在某个服务器上就行了，这样session会一直在对应的服务器上。当服务器A挂了，此时会故障转移到B，依然要从新登陆。

session同步

既然粘滞不行，那把session同步可行吗，当用户登陆服务器A的时候，把A的信息也同步到B。这样无论怎么轮询，都能找到session。问题有如下几个：
一、每一个服务器都存放全部的session的信息，内存占用空间大。
二、每次session变更都要同步，占用网络，网络的延迟还会形成局部时间的不同，也就是当前系统有状态了，好比A还没同步sessoin到B，用户访问了B，又要从新登陆。
三、服务器间的session同步难度比较高，若是没有服务发现，扩容的时候还须要知道对应的ip和端口。
四、服务器A重启后，session还没同步过来，访问服务器A的用户要从新登陆。

存放redis

同步是把session存放在内存中的，那咱们能够提取出来，放在redis中。

经过redis的方案，能够保证服务的无状态，便于扩容，保证了session的一致性。
缺点：
一、引入redis，还要保证redis的高可用，增长了系统的复杂性。

JWT

上面是session存放服务端的方案，咱们也能够经过jwt方式存在客户端。

缺点以下：
一、生成的字符串长，每次传输占用带宽。
二、服务器解析须要占用cpu。
三、没办法注销。
四、若是想改变失效时间，就要从新生成jwt。