三种保持会话的方式
（一）session机制保持会话
存在的问题
- 高并发情况下，会占用服务器大量内存
- 分布式（一个业务分成几个子业务，部署在多个服务器）或者集群（一个业务部署在多个服务器）的时候，session不能共享。
解决方案
- 高并发的时候可以将session存储到redis，如果用户长时间没有访问，将session存储到redis，就减少了服务器的压力。
- 分布式或者集群的时候，先通过redis来判断用户状态也可以实现session共享.
（二）cookie机制保持会话
使用的方法
- 登录验证后，创建登录凭证（比如：用户id+登录时间+过期时间），将登录凭证进行加密（为了避免暴露信息），加密后写到浏览器的cookie，以后，每次请求都发送cookie，服务器根据对应的解密算法对其进行验证（或者将加密过的cookie内容存储到数据库，请求服务器的时候，服务器在数据库进行查找）。
存在的问题
- 每次访问都提交cookie，增加请求量
- 其他访问可能需要cookie（比如说购物车的信息存放在cookie），浏览器对每个域存储的cookie的大小有限制，那么需要控制加密后的凭证。
（三）token机制保持会话
使用方法
- cookie 和session依赖于浏览器，如果客户端不是浏览器，那么需要手动添加token（和cookie类似，也是登录凭证），将token添加到http header或者做为参数添加到url。
存在的问题
- 每次访问的时候手动添加token
- 和cookie 的方式一样增加了请求量
总结
不同的方式适合不同的应用场景，视情况使用。
相同点
- 所有的方式目的都是为了验证用户状态。
- 都需要在客户端存储凭证。
不同点
- 第一种是通过是通过空间换时间，消耗内存存储session对象，但是判断用户状态不用复杂的逻辑。第二种第三种用时间换空间，在服务器端逻辑处理进行判断用户状态。