session 共享问题

如果是工程搭载 在一个服务器上的时候问题 不会出现 但是如果多台合作的时候 session共享问题 就出现了

1.session是什么

• http请求是一次短链接的请求，客户端如果每一次访问没有什么标识的话，就会不断的任务新的客户在请求页面，也没有办法进行下一步操作，这个时候就出现了session。服务器为每位客户创建的会话，存储用户的信息，以便于在用户多次请求的时候，能够定位于相同的客户。

2.自己出现的问题

• 在一个项目中，其中是开启两个war包的，但是我去访问一个war的时候，里面的页面有的是从另一个war中得到，期间访问的时候就会有403的错误，开始没有发现是什么问题，最后在查看JESIONID的时候发现了不同，是session没有共享的问题。导致一个war的权限不够，从而不能进去，通过这次的事情，深入探讨了session共享的问题。

3.方案的总结

• web-server 自身纵向同步
  
  • web-server 之间互相进行同步，就是每一个web-server 都包含session的全部信息，但是 随着session的增大，内存的大小会有很大的限制。
• cookie的保存
  
  • 通过客户端的cookie来进行保存session的对话，服务器通过一定的加密算法进行加密cookie的消息，返回给客户端，客户端每次请求带上对应的cookie即可。
  • 优点：对服务器压力减少，压力分散到客户端（可忽略）
  • 缺点：安全性并不高，加大了宽带的大小，cookie本身在浏览器上也有限制。
• nginx 反向代理
  
  • nginx的反向代理性能极好，在nginx这一层可以进行hash列表的存放，session为key，反向代理的web-server IP地址为value，这样的话，客户每次就能定位到自己已经记录的web-server 进行处理了。
  • 优点：服务器的代码不需要进行改变，而且负载均衡
  • 缺点：hash 过大，需要rehash的时候，可能会导致session的丢失；.如果一个web-server 挂了 这台的session也会没有；session 还是存在服务器的内存中，随session的增多，内存会出现瓶颈。
• db的保存
  
  • 很显然，就是将session保存在数据库中，每次客户返回的时候，就进行mysql的查询是否存在即可。
  • 优点：将session的保存放在的外面，web-server不用存session，对web-server的内存是一种解放。web-server 如果有一台挂了，不会影响到客户的session问题。
  • 缺点：就是加大的数据库的访问，使用线程池的话，频繁的占用，导致其他的业务可能运行较慢。session是有时长的，需要过段时间进行清理数据库的dead的session。
• redis的保存
  
  • 通过redis进行缓存session的数据。
  • 优点：db的保存都有，缓存数据快，没有像db读写在硬盘上。百万级别的数据能够支撑，有集群扩展好。保存的时候可以进行设置时间，这样可以对dead的session进行清理了。
  • 缺点：对内网的添加了一次请求，对内网的传输要求变高了。

4.总结

• 通过这些要求的，我个人更加倾向于redis的保存，在现在微服务的潮流里面，session共享的问题变的突出，redis 刚好能够进行解决这个问题。希望之后能够出来更好的方案。

参考网址一