前言
沉思君在之前的文章《谈谈HTTP状态保持》里介绍了有关HTTP状态保持的知识点,我们知道HTTP协议本身是无状态的,因此在使用HTTP协议进行通信的过程中,需要借助Session机制进行状态的保持。然而在大型网站中,我们的服务器数量通常不止一台,可能是几十台甚至几百台之多,用户发起的HTTP请求通常要经过像Ngnix之类的负载均衡器之后,再路由到具体的服务器上,由于Session默认是存储在单机服务器内存中的,因此在分布式环境下同一个用户发送的多次HTTP请求可能会先后落到不同的服务器上,导致后面发起的HTTP请求无法拿到之前的HTTP请求存储在服务器中的Session数据,从而使得Session机制在分布式环境下失效。
因此在分布式环境下,要使用Session机制进行状态保持,需要采取额外的手段,在这里介绍常见的4种解决方案:Session集中式存储、Session复制、Session Sticky、Cookie Based。
Session集中式存储
Session集中式存储是指将原先存储在单机服务器内存中的Session数据集中存储起来,比如说存储在分布式缓存Redis集群中。其原理是以SessionId作为Key,序列化后的HttpSession对象作为Value存储在Redis中,然后将SessionId返回给客户端,当下一次客户端发送HTTP请求到服务器的时候,会带上这个SessionId,服务器再根据SessionId从Redis拿到相应的Session数据并反序列化成HttpSession对象。由于对HttpSession对象进行了集中存储,而不是存储在服务器本地内存,所以即使同个用户的多次HTTP请求落到不同的服务器上,也能将SessionId与相应的HttpSession对象关联起来,从而实现分布式环境下的Session共享。那么问题来了,这种解决方案有什么优缺点呢?欢迎在评论区留下你的答案。
Session复制
Session复制从另一个角度解决分布式Session问题。前文说到,Session机制在分布式环境下失效的原因是每台服务器上只存储了部分客户端的Session信息,那么我们只要保证每台服务器上都存储了所有客户端的Session信息不就解决问题了吗?Session复制就是基于这个思路实现的,当客户端在某台服务器上存储了Session数据的时候,我们可以手动地将该Session信息同步到集群中的其他服务器上面去,这样一来所有服务器就都存储了所有客户端的Session信息了,因此即使同个客户端的多次HTTP请求落到不同的服务器上面去,也还是能够拿到相应的Session信息,故而也解决了Session分布式问题。实际上,一些开源的Web容器可以支持Session复制,如:Tomcat,因此实施起来难度不大。同样地,这种解决方案也是有利弊的,可以在评论区留下你的答案。
Session Sticky
从另一个角度来说,分布式环境下Session失效也可以说是因为同个客户端在多次请求之间落到不同的服务器上导致的。因此,如果能够保证同个客户端发起的HTTP请求都由相同的服务器进行处理,那么也可以避免Session失效的问题。比如说,Nginx有一种称为IP Hash的负载均衡策略,其可以实现相同IP发送的HTTP请求都路由到同一台服务器上面去,故而也能解决Session分布式问题。同样地,在评论区讨论这种方案的利弊吧。
Cookie Based
前面所讲的方案都是将Session数据存储在服务器中,其实要实现会话保持,还可以将Session数据存储在客户端,常见的方案是存储在Cookie中,这样一来服务器就无需维护客户端的状态,即服务器“无状态化”,无状态化的好处是利于服务器水平扩展。比如:JWT就是基于Cookie实现用户认证功能的,有兴趣的朋友可以去了解下。那么这种方案有何优缺点呢?评论区见。
领取专属 10元无门槛券
私享最新 技术干货