1.session在分布式下的问题
1.同一个服务,多个实例,每次的session分布不一样
解决办法:
第一种解决方案:session复制(同步),存在带宽,占用很多内存
第二种解决方案:客户端存储,浏览器cookie有有长度限制,不安全
第三种解决方案:iphash一致性,水平扩展会有问题
第四种:统一存储到数据库,使用了springsession,将用户的信息存储到了redis缓存中
2.不同服务,跨域名不能共享session
解决办法:
将域名范围扩大为父域名
springsession的原理:
通过过滤器来拦截请求,将request和response包装成wrappedRequest和wrappedResponse,做了功能增强,这样request.getSession就是从SessionRepository获取得到的,做到从redis获取session。
2.threadlocal
添加商品到购物车,要判断用户有没有登录,没有登录就操作临时购物车,登录了就操作登录购物车并且还要合并临时购物车
然后通过拦截器来拦截判断用户是否登录,然后将用户的信息封装起来,放到threadlocal中
3.缓存数据一致性的解决方案
1.双写模式
-
解决方案:1)给缓存数据设置过期时间,数据最终一致性(看用户是否可以忍受)
2)加读写锁
-
失效模式
解决方案:加读写锁
3.延时双删
4.canal来监听mysql的binlog日志,然后更新redis
5.分布式的读写锁
4.微博登录的流程
首先去微博开放平台去申请一个应用,申请成功就会有对应的App Key和App Secret,设置授权成功页的回调地址和授权失败的回调地址。然后你在页面上点击微博登录会跳到微博提供的授权页,输入账号密码,如果成功就会跳到成功回调页,并且它携带了一个code,通过code来获取token,拿得token就可以访问微博提供的一些接口来访问用户信息
5.单点登录流程
环境:一台登录认证服务(server),两台客户端(client1,client2)
浏览器从client1访问受保护的资源,判断session中有没有用户信息,如果没有去认证服务器登录,可以携带一个登录成功要跳转的地址(redirect_url),登录成功可以把用户信息放入redis中,然后跳转地址的使用携带一个token,说明token是从认证服务登录返回的,判断如果token不为空,根据token查询用户信息放入session中,以后登录session有数据就可以直接访问了,client2访问受保护的资源,client1已经登录过了,所以client2就不需要登录了,就是服务器返回token的时候会往浏览器放一个cookie,下次登录判断cookie是否为null,如果不为null就说明以前有人登录过了,就不需要登录了