分布式session问题

分布式session问题

问题： 假设我们登录，每个用户登录会分配一个session空间，当只有一台Tomcat服务器时，并不会出现分布式session问题，但一台Tomcat服务器的并发量有限，在大型项目中会配置多台Tomcat服务器，采用Nginx代理分发，而Nginx是采用轮询机制进行分发服务器的，那就会出现一个问题，假设用户A在Tomcat01进行登录操作，但过了一阵后再次进行请求被分配的Tomcat02，而由于session空间没进行同步操作，从而导致用户A需要重新登录。这就是分布式session问题。

解决方案：

方案一: session复制

• 优点

  • 无需修改代码，只需要修改Tomcat配置

• 缺点

  • session同步传输占内网带宽
  • 多台Tomcat同步性能指数级下降
  • session占用内存，无法有效扩展

方案二：前端存储

• 优点

  • 不占用服务端内存

• 缺点

  • 存在安全风险
  • 数据大小受cookie限制
  • 占用外网带宽

方案三：session粘滞（nian zhi）

粘性session：
apache服务器会把某个用户的请求，交给tomcat集群中的一个节点，以后此节点就负责该保存该用户的session，如果此节点挂掉，那么该用户的session也会消失。
非粘性session：
这种方式下，Nginx通过负载均衡器根据节点的情况，把用户的请求进行分发，复制多份session给多个节点，这样，如果节点中其中一个session挂掉的话，其它的还能继续工作，也就是只要有一个节点没有挂掉，该用户的信息就不会消失。

• 优点

  • 无需修改代码
  • 服务端可以水平扩展

• 缺点

  • 增加新机器，会重新hash，导致重新登录
  • 应用重启，需要重新登录

方案四：后端集中存储

• 优点

  • 安全
  • 容易水平扩展

• 缺点

  • 增加复杂度
  • 需要修改代码