共计 841 个字符，预计需要花费 3 分钟才能阅读完成。
单机模式
浏览器第一次拜访服务器的时候，服务器会创立一个 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。
