session一致性

单机模式

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

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

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

集群模式

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

session粘滞

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

session同步

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

存放redis

同步是把session存放在内存中的，那我们可以提取出来，放在redis中。

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

JWT

上面是session存放服务端的方案，我们也可以通过jwt方式存在客户端。

缺点如下：
1、生成的字符串长，每次传输占用带宽。
2、服务器解析需要占用cpu。
3、没办法注销。
4、如果想改变失效时间，就要重新生成jwt。