一、分布式session
因为是分布式的系统，传统的单机session不适用于分布式系统中，可以使用分布式session。
本质是使用第三方的数据库（建议是非关系型数据库）来存储session信息，例如Redis、Mongo DB，可以使用spring 提供的spring session组件
用户登录请求发送到服务器后，服务器进行校验，如果通过，服务器会使用session把用户的信息临时保存在了服务器上，客户端同时也会存将session信息存储在cookie上，离开网站后session会被销毁。
Session共享问题
是指在一个浏览器访问多个 Web 服务时，服务端的 Session 数据需要共享。
方案：
Session 复制
通过对应用服务器的配置开启服务器的 Session 复制功能，在集群中的几台服务器之间同步 Session 对象，使得每台服务器上都保存所有的 Session 信息，这样任何一台宕机都不会导致 Session 的数据丢失，服务器使用 Session 时，直接从本地获取。这种方式的缺点也比较明显。因为 Session 需要时时同步，并且同步过程是有应用服务器来完成，由此对服务器的性能损耗也比较大。
Session 服务器
Session 服务器可以解决上面的所有的问题，利用独立部署的 Session 服务器统一管理 Session，服务器每次读写 Session 时，都访问 Session 服务器。 对于 Session 服务器，我们可以使用 Redis 或者 MongoDB 等内存数据库来保存 Session 中的数据，以此替换掉服务中的 HttpSession。达到 Session 共享的效果。
二、Token
近年来，基于token的认证开始成为主流，客户端登陆成功后，服务端会加密生成一个token并把它返还给客户端，客户端存起来，之后发起请求后可以在header里存放对应属性达到鉴权的目的。
当客户端再发送请求时，服务端可以通过解密，解析出用户的信息，从而进行鉴权校验。
token相比其他验证方式，主要是无需每次都去验证用户名密码，同时由于token保存在前端，服务端无需保存每个用户的登录状态，只需要验证访问时带着的token是不是自己签发的，可以减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。
token存在的问题：
1.刷新问题及过期失效问题
参考spring security oauth2 的双token机制
2.Token被截取问题
使用https连接
三、Token和session的比较
Session的弊端
1、服务器压力增大
通常session是存储在内存中的，每个用户通过认证之后都会将session数据保存在服务器的内存中，而当用户量增大时，服务器的压力增大。（可以将数据保存在磁盘中）
2、CSRF跨站伪造请求攻击
session是基于cookie进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
3、扩展性不强
如果将来搭建了多个服务器，虽然每个服务器都执行的是同样的业务逻辑，但是session数据是保存在内存中的（不是共享的），用户第一次访问的是服务器1，当用户再次请求时可能访问的是另外一台服务器2，服务器2获取不到session信息，就判定用户没有登陆过。（可以使用分布式session将session在各个集群中保持一致）
Token可以有效解决session的CSRF跨站伪造请求攻击，虽然token也有被截取的风险，但是可以通过https加密及合理设置token的有效时间及刷新时间来解决。
以上仅对个人学习过程中的一些问题进行记录
