[会话共享]

App后端会话共享

• 通过nignx请求转发，到不同的应用模块中，需要判断用户有没有登陆验证通过
• app的移动端没有cookie,session机制
• 使用session外置方式解决，用redis统一管理session,用redis来模拟session
• 移动端的session都是无状态的，不创建session,我们通过用户登陆时生成一个token(session) ，token存在redis设置超时，用户每次请求都带着token到服务端做校验，token代表唯一用户

Web后端session

• 给Web站点使用负载均衡之后，必须面临的一个重要问题就是Session处理，使用服务器保存Session在做负载均衡时都需要考虑Session
• 当一个用户第一次访问被负载均衡代理到后端服务器A并登录后，服务器A上保留了用户的登录信息；当用户再次发送请求时，根据负载均衡策略可能被代理到后端不同的服务器，例如服务器B，由于这台服务器B没有用户的登录信息，所以导致用户需要重新登录。这对用户来说是不可忍受的
• 一般有session保持/session复制/session共享

会话保持

• 会话保持，负载均衡进行请求分发的时候保证每个客户端固定的访问到后端的同一台应用服务器

• 会话保持方案在所有的负载均衡都有对应的实现。而且这是在负载均衡这一层就可以解决Session问题

• 优点：实现简单

• 缺点：使用会话保持无法保证负载绝对均衡；

Nginx负载均衡实现session保持

nginx的upstream目前支持5种方式的分配方式，其中有两种比较通用的Session解决方法，ip_hash和url_hash（不是官方模块，需要额外安装）

• ip_hash：每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，达到了Session保持的方法；如果后端有服务器宕机，那么这台服务器的Session丢失，被分配到这台服务请求的用户还是需要重新登录

    upstream bakend {
       ip_hash;
       server192.168.0.11:80;
       server192.168.0.12:80;
     }
  

Haproxy做负载均衡的Session保持

会话复制

• 将每个应用服务器中的Session信息复制到其它服务器节点上
• 会话复制在Tomcat上得到了支持，它是基于IP组播（multicast）来完成Session的复制

会话共享

用Redis等高性能的缓存数据库来保存session