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

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

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

在介绍会话保持技术之前,我们必须先花点时间弄清楚一些概念:什么是连接(Connection)、什么是会话(Session),以及这二者之间的区别。需要特别强调的是,如果我们仅仅是谈论负载均衡,会话和连接往往具有相同的含义。

从简单的角度来看,

如果用户需要登录,那么就可以简单的理解为会话;

如果不需要登录,那么就是连接。

实际上,会话保持机制与负载均衡的基本功能是完全矛盾的。负载均衡希望将来自客户端的连接、请求均衡的转发至后端的多台服务器,以避免单台服务器负载过高;而会话保持机制却要求将某些请求转发至同一台服务器进行处理。因此,在实际的部署环境中,我们要根据应用环境的特点,选择适当的会话保持机制。

原始负载均衡的基本原理

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

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

看了这段文字之后,应该就能够很好的理解为什么负载均衡的硬件设备的发展速度,无法和软件的发展相比较。因为这个硬件的发展速度,比不上服务器的发展速度….

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

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会将不常用的部分删除,但是如果用户隔离了一段时间之后继续使用,已经全部乱套了。

时间: 2024-11-08 21:03:58

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

会话保持:粘滞会话

会话保持是负载均衡中最常见的问题之一,也是一个相对于比较复杂的问题.会话保持有时候又被叫做粘滞会话(Sticky Sessions).会话保持是指在负载均衡器上的一种机制,可以识别客户端与服务器之间交互过程的关联性,在做负载均衡的同时还保证一系列相关联的访问请求会保持分配到一台服务器上. 会话保持的使用场景 在讨论这个话题之前,必须要先花一点时间弄清楚一些概念:什么是连接(Connection).什么是会话(Session),以及这两者之间的区别.需要特别强调的是,如果我们仅仅是讨论负载均衡,会

Linux文件和目录的粘滞位(sticky bit)带来的困惑(转)

今天维护系统时发现一个非常诡异的问题:AAA用户和BBB用户同属AAA组,但用AAA用户创建的文件,权限设置为777后,还是不能用BBB用户删除.诡异! 几经周转,发现AAA用户创建文件位置的上层目录的权限是drwxrwxrwt,做开发这么多年了,还没见过所谓"t"的权限,于是找了一位公司的linux大师帮忙,大师噼里啪啦的做了一堆试验后,然后在google上搜索"rwt linux",终于发现了问题,发现这种用法的名字是"文件的粘滞位(sticky)位&

Linux文件和目录的粘滞位(sticky bit)

今天维护系统时发现一个非常诡异的问题:AAA用户和BBB用户同属AAA组,但用AAA用户创建的文件,权限设置为777后,还是不能用BBB用户删除.诡异! 几经周转,发现AAA用户创建文件位置的上层目录的权限是drwxrwxrwt,做开发这么多年了,还没见过所谓"t"的权限,于是找了一位公司的linux大师帮忙,大师噼里啪啦的做了一堆试验后,然后在google上搜索"rwt linux",终于发现了问题,发现这种用法的名字是"文件的粘滞位(sticky)位&

【转】Linux中的特殊权限粘滞位(sticky bit)详解

在linux下每一个文件和目录都有自己的访问权限,访问权限确定了用户能否访问文件或者目录和怎样进行访问.最为我们熟知的一个文件或目录可能拥有三种权限,分别是读.写.和执行操作,在这里不做详细说明.我们创建一个文件后系统会默认地赋予所有者读和写权限.当然我们也可以自己修改它,添加自己需要的权限. 特殊权限 但是这三种权限就足够了吗?我们现在来说说在linux下的另一个特殊权限.首先我们来看看在根目录下的一个目录tmp,可以看到tmp目录的other权限是'rwt',那么这里的t又是什么权限呢,有什

nginx负载均衡LAMP及基于memcached实现php会话保存

逻辑架构图: 实验准备: 虚拟机: 172.18.250.75    nginx反代     keepalived高可用 虚拟机: 172.18.250.76    nginx反代     keepalived高可用 虚拟机: 172.18.250.77    LAMP           memcached服务 虚拟机: 172.18.250.78    LAMP           共享memcached 实验要求: 两台nginx反向代理服务实现负载均衡,并实现高可用,两台后端服务器提供w

nginx负载均衡基于ip_hash的session粘帖

nginx可以根据客户端IP进行负载均衡,在upstream里设置ip_hash,就可以针对同一个C类地址段中的客户端选择同一个后端服务器,除非那个后端服务器宕了才会换一个. nginx的upstream目前支持的5种方式的分配 1.轮询(默认) 每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除. upstream backserver { server 192.168.0.14; server 192.168.0.15; } 2.指定权重 指定轮询几率,wei

负载均衡 > 常见问题

证书管理相关问题 常用证书申请流程 1.本地生成私钥:openssl genrsa -out privateKey.pem 2048 其中privateKey.pem为您的私钥文件,请妥善保管. 2.生成证书请求文件:openssl req -new -key privateKey.pem -out server.csr其中server.csr是您的证书请求文件,可用其去申请证书. 3.获取请求文件中的内容前往CA等机构站点申请证书. 证书格式要求 您要申请的证书为:linux环境下pem格式的

文件的三种特殊权限——suid、sgid和粘滞位(sticky)

文件的正常权限是首选对用户进行分组:文件属主,文件属组和其它.然后每组类用户对文件具有三种基本的权限:r,w,x.除了这些正常的权限设置,还可以设置三种特殊权限. 1. suid.任何用户执行设置有该权限的文件后,不再以用户自己的身份作为进程的属主,而是以该执行文件的属主作为进程的属主.这种权限的实质就是让执行该文件的用户,在进程运行过程中被授予文件属主的身份. 举例: -rwsr-xr-x. 1 root root 48568 Sep 10 14:24 /tmp/cat 任何用户运行cat时,

负载均衡(转)

概述 在分布式系统中,负载均衡(Load Balancing)是一种将任务分派到多个服务端进程的方法.例如,将一个HTTP请求派发到实际的Web服务器中执行的过程就涉及负载均衡的实现.一个HTTP请求到达Web服务器,这中间涉及多个过程,也存在多种不同负载均衡的方法.本文讲述负载均衡的基本原理与派发策略,下图1是负载均衡的基本原理图,图1中客户端的请求请求经过达负载均衡器(Load Balancer)的分派,被指定的服务器进程进行处理. 图1:负载均衡基本原理 实现负载均衡主要有两个目的.第一个