负载均衡常见问题之会话保持-粘滞会话(Sticky Sessions)

 

会话保持是负载均衡最多见的问题之一,也是一个相对比较复杂的问题。数据库

会话保持有时候又叫作粘滞会话(Sticky Sessions)。后端

在介绍会话保持技术以前,咱们必须先花点时间弄清楚一些概念:什么是链接(Connection)、什么是会话(Session),以及这两者之间的区别。须要特别强调的是,若是咱们仅仅是谈论负载均衡,会话和链接每每具备相同的含义。浏览器

从简单的角度来看,安全

若是用户须要登陆,那么就能够简单的理解为会话;服务器

若是不须要登陆,那么就是链接。网络

实际上,会话保持机制与负载均衡的基本功能是彻底矛盾的。负载均衡但愿未来自客户端的链接、请求均衡的转发至后端的多台服务器,以免单台服务器负载太高;而会话保持机制却要求将某些请求转发至同一台服务器进行处理。所以,在实际的部署环境中,咱们要根据应用环境的特色,选择适当的会话保持机制。session

 

原始负载均衡的基本原理并发

对于同一个链接中的数据包,负载均衡会将其进行NAT转换后,转发至后端固定的服务器进行处理,这是负载均衡最基本、最原始的功能。负载均衡系统内部会专门有一张表来记录这些链接的情况,包括:[源IP:端口]、[目的IP:端口]、[服务器IP:端口]、空闲超时时间(Idle Timeout)等等。负载均衡

因为负载均衡内部记录链接状态的这张表须要消耗系统的内存资源,所以,这张表不可能无限大,全部厂家都会有必定的限制。这张表的大小通常称之为最大并发链接数,也就是系统同时可以容纳的链接数量。考虑到创建这些链接的客户端或服务器会发生一些异常情况,致使这些链接不能被正常终结掉,所以,负载均衡的当前链接状态表项中,设计了一个空闲超时时间的参数。这个参数定义为,当该链接在必定时间内无流量经过时,负载均衡会自动删除该链接条目,释放系统资源。memcached

看了这段文字以后,应该就可以很好的理解为何负载均衡的硬件设备的发展速度,没法和软件的发展相比较。由于这个硬件的发展速度,比不上服务器的发展速度….

 

有了会话以后,使用原始的负载均衡就会有问题,常见的异常场景包括:

1.        客户端输入了正确的用户名和口令,但却反复跳到登陆页面;

2.        用户输入了正确的验证码,可是总提示验证码错误;

3.        客户端放入购物篮的物品丢失

4.        …

所以,会话保持机制的意义就在于,确保未来自相同客户端的请求,转发至后端相同的服务器进行处理。换句话说,就是将客户端与服务器之间创建的多个链接,都发送到相同的服务器进行处理。若是在客户端和服务器之间部署了负载均衡设备,颇有可能,这多个链接会被转发至不一样的服务器进行处理。若是服务器之间没有会话信息的同步机制,会致使其余服务器没法识别用户身份,形成用户在和应用系统发生交互时出现异常。

 

在大多数电子商务的应用系统或者须要进行用户身份认证的在线系统中,一个客户与服务器常常通过好几回的交互过程才能完成一笔交易或者是一个请求的完成。因为这几回交互过程是密切相关的,服务器在进行这些交互过程的某一个交互步骤时,每每须要了解上一次交互过程的处理结果,或者上几步的交互过程结果,服务器进行下一步操做时须要这就要求全部这些相关的交互过程都由一台服务器完成,而不能被负载均衡器分散到不一样的服务器上。

 

而这一系列的相关的交互过程多是由客户到服务器的一个链接的屡次会话完成,也多是在客户与服务器之间的多个不一样链接里的屡次会话完成。不一样链接的屡次会话,最典型的例子就是基于http的访问,一个客户完成一笔交易可能需屡次点击,而一个新的点击产生的请求,可能会重用上一次点击创建起来的链接,也多是一个新建的链接。

 

会话保持就是指在负载均衡器上有这么一种机制,能够识别作客户与服务器之间交互过程的关连性,在做负载均衡的同时,还保证一系列相关连的访问请求会保持分配到一台服务器上。

 

简单会话保持

 

简单会话保持也被称为基于源地址的会话保持,也叫基于IP的会话保持,是指负载均衡器在做负载均衡时是根据访问请求的源地址做为判断关连会话的依据。对来自同一IP地址的全部访问请求在做负载均时都会被保持到一台服务器上去。在BIGIP设备上能够为“同一IP地址"经过网络掩码进行区分,好比能够经过对IP地址 192.168.1.1进行255.255.255.0的网络掩码,这样只要是来自于192.168.1.0/24这个网段的流量BIGIP均可以认为他们是来自于同一个用户,这样就将把来自于192.168.1.0/24网段的流量会话保持到特定的一台服务器上。

 

简单会话保持里另一个很重要的参数就是链接超时值,BIGIP会为每个进行会话保持的会话设定一个时间值,当一个会话上一次完成到这个会话下次再来以前的间隔若是小于这个超时值,BIGIP将会将新的链接进行会话保持,但若是这个间隔大于该超时值,BIGIP将会将新来的链接认为是新的会话而后进行负载平衡。

注意:会话保持时间和链接保持时间不同

 

简单会话保持实现起来简单,只须要根据数据包三、四层的信息就能够实现,效率也比较高。

 

F5对会话保持的支持

 

F5 BigIP支持多种的会话保持方法,其中包括:简单会话保持(源地址会话保持)、HTTP Header的会话保持,基于SSL Session ID的会话保持,I-Rules会话保持以及基于 HTTP Cookie的会话保持,此外还有基于SIP ID以及Cache设备的会话保持等,但经常使用的是简单会话保持,HTTP Header的会话保持以及 HTTP Cookie会话保持以及基于I-Rules的会话保持。

 

NginX对简单会话保持的支持

ip_hash 
每一个请求按访问ip的hash结果分配,这样每一个访客固定访问一个后端服务器,能够解决session 的问题。
例如:
    upstream bakend {
        ip_hash;
        server 192.168.0.14:88;
        server 192.168.0.15:80;
    }

 

简单会话保持存在的问题就在于当多个客户是经过代理或地址转换的方式来访问服务器时,因为都分配到同一台服务器上,会致使服务器之间的负载严重失衡。另一种状况上客户机数量不多,但每一个客户机都会产生多个并发访问,对这些必发访问也要求经过负载均衡器分配到多个服器上,这时基于客户端源地址的会话保持方法也会致使负载均衡失效。这个时候,就必需要考虑使用其余的会话保持方式,好比session等。

        

         若是使用硬件做为负载均衡设备,若是遇到一些特殊的状况,须要进行个性化定制,实际上是很是有难度和挑战的,再更加多的时间,其实这是根本走不通的,若是使用软件,好比Nginx或者Apache,咱们能够对它进行必定程度上的订制,尽量多的知足业务要求。

         一些其余的会话保持的方法

使用数据库存放session

Session信息存储到数据库表,这样实现不一样应用服务器间Session信息的共享。

1.   适合数据库访问量不大的网站

     优势:实现简单 
     缺点:因为数据库服务器相对于应用服务器更难扩展且资源更为宝贵,在高并发的Web应用中,最大的性能瓶颈一般在于数据库服务器。所以若是将 Session存储到数据库表,频繁的数据库操做会影响业务。

 

使用文件系统存放session

        经过文件系统(好比NFS方式)来实现各台服务器间的Session共享,各台服务器只须要mount共享服务器的存储Session的磁盘便可,实现较为简单。但NFS 对高并发读写的性能并不高,在硬盘I/O性能和网络带宽上存在较大瓶颈,尤为是对于Session这样的小文件的频繁读写操做。 

       适合并发量不大的网站.

 

基于浏览器Cookie的Session共享 
      此种方案把用户相关的Session信息存储到浏览器的Cookie中,也称为客户端Session。 
      采用Flash Cookie、URL重写的方式传递Session信息的方案也能够归为此类。 
      缺点:只可以存储字符串、数值等基本类型的数据;Cookie大小存在限制;安全性;带宽及数据解压缩、网络传输性能问题。

 

基于Memcached 存储Session 

利用Memcached来保存Session数据,直接经过内存的方式,效率天然可以提升很多。 在读写速度上会比 files 时快不少,并且在多个服务器须要共用 session 时会比较方便,将这些服务器都配置成使用同一组 memcached 服务器就能够,减小了额外的工做量。 缺点: session 数据都保存在 memory 中,一旦宕机,数据将会丢失。但对 session 数据来讲并非严重的问题。若是网站访问量太大,session太多的时候,memcached会将不经常使用的部分删除,可是若是用户隔离了一段时间以后继续使用,已经所有乱套了。

相关文章
相关标签/搜索