保持会话

三种保持会话的方式

（一）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对象，但是判断用户状态不用复杂的逻辑。第二种第三种用时间换空间，在服务器端逻辑处理进行判断用户状态。