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就说明以前有人登录过了，就不需要登录了