在单服务器环境中,不要考虑session问题,但是单服务器宕机的情况会导致服务中断,这是很多对应用服务可用性要求较高的客户所不希望的。所以很多客户都会提出 应用服务集群。
用两台及以上服务器组件集群,一般客户会是通过 负载均衡设备进行,如深信服、F5品牌的设备。
可以将所有要访问应用服务器的请求 都通过 负载均衡设备进行 转发,由负载均衡设备对 应用服务器进行 轮询,确认服务还活着,然后再将请求分配给活着的服务并记录分配情况。
那么会出现一种问题,我们都知道session是存在于服务器端,通过负载均衡设备在不设置的情况下进行分发请求是随机指定服务器。也就是说 一个客户端 一开始访问是 是A服务器 ,session是由服务器A生成,如果客户端下次的请求被分配到B服务器上,因为session的确认,就需要客户重新进行登录,这当然很不方便了。
无论是使用物理的分发设备还是 类似于Apache、Ngix软设备解决这种问题需要进行会话保持处理,主要有两个方法:
Session-sticky 粘性会话,即通过负载均衡设备分发时,可以根据客户端的地址指定 它所访问的服务器,如用户甲 访问服务,负载均衡设备会随机分发到活着的服务A,然后建立起 用户甲与服务的对应关系,在会话有效期内用户甲的访问都会只被分配到A,这样就保证了session的连续可用。
Session-replication 复制会话信息,即设置应用服务器中间件通过转发session信息,实现session的共享,在A、B两台服务器都会持有对应的session信息,这个在tomcat中间件中有特殊的配置可以实现。