应用服务器的高可用架构设计主要基于服务无状态这一特性,但是事实上,业务总 是有状态的,
Web 应用中将这些多次请求修改使用的上下文对象称作会话(Session) 单机情况下,Session 可由部署在服务器上的Web 容器( 如Tomcat) 管理 在使用负载均衡的集群环境中,由于负载均衡服务器可能会将请求分发到集群中的任何一台应用服务器上,所以保证每次请求依然能够获得正确的Session比单机时要复杂很多
集群环境下,Session 管理主要有以下几种手段
Session 复制是早期系统使用的一种服务器集群Session管理机制 应用服务器开启Web 容器的Session复制功能,在集群中的几台服务器之间同步Session对象, 使得每台服务器上都保存所有用户的Session信息,这样任何一台机器宕机都不会导致 Session 数据的丢失,而服务器使用Session 时,也只需要在本机获取即可
使用Session复制实现应用服务器共享Session
虽然简单,从本机读取Session信息也很快速,但只能使用在集群规模比较小的情况下
可以利用负载均衡的源地址Hash算法实现
负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上(也可以根据Cookie信息将同一个户的请求总是分发到同一台服务器上,当然这时负载均衡服务器必须工作在HTTP 协议层) 这样在整个会话期间,用户所有的请求都在同一台服务器上处理,即Session绑定在某台特定服务器上,保证Session总能在这台服务器上获取
利用负载均衡的会话黏滞机制将请求绑定到特定服务器
但是Session绑定的方案显然不符合我们对系统高可用的需求
一旦某台服务器宕机,那么该机器上的Session也就不复存在了,用户请求切换到其他机器后因为没有Session而无法完成业务处理
因此虽然大部分负载均衡服务器都提供源地址负载均衡算法,但很少有网站利用这个算法进行Session管理
早期系统使用C/S架构,一种管理Session的方式是将Session记录在客户端,每次请求服务器的时候,将Session放在请求中发送给服务器,服务器处理完请求后再将修改过的Session响应给客户端 如今的B/S架构,网站没有客户端,但是可以利用刘览器支持的Cookie记录Session
利用Cookie 记录Session信息
但是
由于Cookie的
因此事实上,许多网站都或多或少地使用Cookie记录Session。
那么有没有可用性高、伸缩性好、性能也不错,对信息大小又没有限制的服务器集群Session管理方案呢?
答案就是Session服务器!利用独立部署的Session服务器(集群)统一管理Session,应用服务器每次读写Session时,都访问Session服务器
利用Session服务器共享Session
这种方案事实上是将应服务器的状态分离,分为
然后针对这两种服务器的不同特性分别设计其架构
对于有状态的Session服务器,一种比较简单的方法是利用
在这些产品的基础上进行包装,使其符合Session 的存储和访问要求。如果业务场景对Session 管理有比较高的要求,比如利用Session 服务集成单点登录(SSO)、用户服务等功能,则需要开发专门的Session服务管理平台。