基于redis解决集群的session共享问题

session共享问题：多台Tomcat并不共享session存储空间，当请求切换到不同tomcat服务时导致数据丢失的问题。

核心思路分析：

每个tomcat中都有一份属于自己的session,假设用户第一次访问第一台tomcat，并且把自己的信息存放到第一台服务器的session中，但是第二次这个用户访问到了第二台tomcat，那么在第二台服务器上，肯定没有第一台服务器存放的session，所以此时 整个登录拦截功能就会出现问题，我们能如何解决这个问题呢？

1.1 早期方案

早期的方案是session拷贝，就是说虽然每个tomcat上都有不同的session，但是每当任意一台服务器的session修改时，都会同步给其他的Tomcat服务器的session，这样的话，就可以实现session的共享了

但是这种方案具有两个大问题

        1、每台服务器中都有完整的一份session数据，服务器压力过大。即占用内存

        2、session拷贝数据时，可能会出现延迟。拷贝期间有用户访问,仍然无法登录

1.2 其他方案

数据库存储等策略

1.3 基于redis解决session共享问题

把session换成redis，redis数据本身就是共享的，就可以避免session共享的问题了

• 数据共享

• 内存存储:较高的读写性能,登录校验等功能需要较高的效率。

• key、value结构

使用随机字符串token代替JsessionId:

在redis中使用手机号作为key,存储该手机号最新的验证码信息（String）；

使用UUID生成随机字符串token作为key,存储该手机号对应的用户User信息(hash结构),并且此token作为类似于session中Jsessionid功能的登陆凭证,将此token返回给前端界面.之后登录校验流程类似于使用session:前端界面再进行登录请求时,会携带着此token进行访问,从redis中取出token对应的value,即为用户User信息。

如果我们采用phone存储用户User信息：手机号这个的数据来存储当然是可以的，但是如果把这样的敏感数据存储到redis中,并且从页面中带过来毕竟不太合适，所以我们在后台生成一个随机串token，然后让前端带来这个token就能完成我们的整体逻辑了

在前端界面common.js中,定义拦截器,对于所有的ajax请求,只要token存在,则作为请求的请求头数据发送到后端,token信息对应的请求头名称为:'authorization'，因此在服务端只需要获取authorization请求头,从而得到此token信息,利用token再得到User对象,实现登陆验证功能。

(首次登录请求会将用户存储到redis中,并向前端返回随机token作为key,之后前端的每个请求都会携带此token作为请求头,服务端利用该请求头(即token数据)得到User对象,实现登陆验证。)

当注册完成后，用户去登录会去校验用户提交的手机号和验证码，是否一致，如果一致，则根据手机号查询用户信息，不存在则新建，最后将用户数据保存到redis，并且生成token作为redis的key，当校验当前请求的用户是否登录时，当前请求携带着token进行访问，从redis中取出token对应的value，判断是否存在这个数据，如果没有则拦截，如果存在则将其保存到threadLocal中，并且放行。实现redis解决session的共享问题。