Session管理

一、web集群应用的Session管理方案

1. Cookie会话保持

• 把session加密后存在cookie中,每次session信息被写在客服端,然后经浏览器再次提交到服务器。
• 即使两次请求在集群中的两台服务器上完成,也可以到达session共享。
• 这种解决方法的优点是session信息不用存放在服务器端,大大减轻了服务器的压力。
• 另一个优点是一个session中的两次或多次请求可以在一个群集中的多个服务器上完成,可以避免单端故障。
• 缺点存在安全问题。

  2. 负载均衡设备

• 典型负载均衡设备F5，F5也提供cookie会话保持功能。
• 记住用户的访问。比如用户第一次访问了群集中A节点，当用户第二次访问时，它也会把用户请求分发到节点A，此特性称为会话自粘型session sticky。
• 如果集群中一台服务器宕机，该服务器上的会话会丢失。
• 一般基于访问ip的hash策略，如果宕机，则等同于单点部署，会丢失，会话不复制。

  3. session replication

• 提供一个群集保存session共享信息.所有应用服务把自己的session信息存放到session群集服务器组，当应用系统需要session信息的时候直接到session群集服务器上读取。
• 所有节点间进行Session数据的同步拷贝，任何一个节点均保存了所有的。
• 例如如tomcat自带session共享。
• 如果其中一台服务器发生故障，根据负载均衡的原理，调度器会遍历寻找可用节点，分发请求，由于session已同步，故能保证用户的session信息不会丢失，会话复制。
• session复制带来的性能损失会快速增加.特别是当session中保存了较大的对象,而且对象变化较快时,性能下降更加显著，会消耗系统性能。这种特性使得web应用的水平扩展受到了限制。并且Session内容通过广播同步给成员，会造成网络流量瓶颈，即便是内网瓶颈。在大并发下表现并不好

  4. 基于cache DB缓存的session共享

• 所有Session数据放到一台服务器上或者数据库中，集群中的所有节点通过访问这台Session服务器来获取数据；
• 基于memcache/redis缓存的session共享.
• 即使用cacheDB存取session信息，应用服务器接受新请求将session信息保存在cache DB中，当应用服务器发生故障时，调度器会遍历寻找可用节点，分发请求，当应用服务器发现session不在本机内存时，则去cacheDB中查找，如果找到则复制到本机，这样实现session共享和高可用。

三、Tomcat集群session同步方案

1. 使用tomcat自带的cluster方式，多个tomcat间自动实时复制session信息，配置起来很简单。但这个方案的效率比较低，在大并发下表现并不好。
2. 利用nginx的基于访问ip的hash路由策略，保证访问的ip始终被路由到同一个tomcat上，这个配置更简单。每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session(并不是共享session解决)的问题! 并且如果应用是某一个局域网大量用户同时登录，这样负载均衡就没什么作用了。
3. 利用nginx插件实现tomcat集群和session同步，nginx-upstream-jvm-route是一个Nginx的扩展模块，用来实现基于Cookie的Session Sticky的功能。但是遗憾的是,这个模块的补丁在nginx1.4版本之后就没有再更新了,所以nginx1.4之后版本跟该模块就不兼容了!!
4. 利用memcached实现（MSM工具）。memcached存储session，并把多个tomcat的session集中管理，前端在利用nginx负载均衡和动静态资源分离，在兼顾系统水平扩展的同时又能保证较高的性能。即通过MSM工具把Tomcat的Session序列化后保存到Memcached里面，从而实现Session共享.
5. 利用redis实现。使用redis不仅仅可以将缓存的session持久化，还因为它支持的单个对象比较大，而且数据类型丰富，不只是缓存 session，还可以做其他用途，可以一举几得。Redis这种方式目前还不支持Tomcat8环境(现在网上插件不支持tomcat8,非要支持tomcat8,则需修改插件jar包的源代码)
6. 利用filter方法实现。这种方法比较推荐，因为它的服务器使用范围比较多，不仅限于tomcat ，而且实现的原理比较简单容易控制。
7. 利用terracotta服务器共享session。这种方式配置比较复杂。

1. 客户端Cookie保存

• 客户端Cookie保存以cookie加密的方式保存在客户端.
• 优点是减轻服务器端的压力，每次session信息被写在客服端,然后经浏览器再次提交到服务器。
• 即使两次请求在集群中的两台服务器上完成，也可以到达session共享。
• 缺点：不安全

  2. Session持久化到数据

• 将session信息存入数据库中，其它应用可以从数据库中查出session信息