会话保持原理

最近更新时间:2018-01-05 11:46:11

会话保持原理

1. 什么是会话保持?

会话保持是负载均衡最常见的问题之一,会话保持是指在负载均衡器上的一种机制,可以识别客户端与服务器之间交互过程的关联性,在负载均衡的同时保证一系列相关联的访问请求会分配到一台服务器上。

2. 连接和会话的区别?

在讨论会话保持前,我们先区分一些概念:什么是连接(Connection)、什么是会话(Session)。需要特别强调的是,如果我们仅仅是谈论负载均衡,会话和连接往往具有相同的含义。从简单的角度来看,如果用户需要登录,那么就可以理解为会话;如果不需要登录,那么就是连接。

3. 什么时候需要会话保持?

对于同一个连接中的数据包,负载均衡会将其进行 NAT 转换后,转发至后端固定的服务器进行处理。负载均衡系统内部会专门有一张表来记录这些连接的状况,包括:[源IP:端口]、[目的IP:端口]、[服务器IP:端口]、空闲超时时间(Idle Timeout)等等。由于负载均衡内部记录连接状态的这张表需要消耗系统的内存资源,因此这张表不可能无限大,所有传统厂商都会有一定的限制。这张表的大小一般称之为最大并发连接数,也就是系统同时能够容纳的连接数量。负载均衡的当前连接状态表项中,设计了一个空闲超时时间(Idle Timeout)的参数。当该连接在Idle Timeout 内无流量通过时,负载均衡会自动删除该连接条目,释放系统资源。

删除连接后,客户端的请求将无法保证继续发往同一个后端服务器,需要遵循负载均衡器的流量分发策略。

在某些要求登录状态的情境下,要求客户端和服务器之间保持一个会话(session)以记录客户端的各种信息。比如在大多数电子商务的应用系统或者需要进行用户身份认证的在线系统中,一个客户端与服务器通常需要经过好几次的交互过程才能完成一笔交易或者是一个请求的完成。由于这几次交互过程是密切相关的,服务器在进行这些交互过程的某一个交互步骤时往往需要了解上一次或上几次的交互过程处理结果,这就要求所有这些相关的交互过程都由一台服务器完成,而不能被负载均衡器分散到不同的服务器上。否则可能出现异常情景:

  • 客户端输入了正确的用户名和密码,但却反复跳到登录页面;
  • 用户输入了正确的验证码,但是总提示验证码错误;
  • 客户端放入购物车的物品丢失;

因此会话保持机制的意义就在于,确保在合适的情境下,将来自相同客户端的请求转发至后端相同的服务器进行处理。如果在客户端和服务器之间部署了负载均衡设备,很有可能这多个连接会被转发至不同的服务器进行处理。如果服务器之间没有会话信息的同步机制,会导致其他服务器无法识别用户身份,造成用户在和应用系统发生交互时出现异常。

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

4. 会话保持的分类

4.1. 简单会话保持(四层会话保持)

简单会话保持(也称作基于源地址的会话保持、基于 IP 的会话保持)是指负载均衡器在作负载均衡时根据访问请求的源地址作为判断关联会话的依据。对来自同一IP地址的所有访问请求在作负载均时都会被保持到一台服务器上去。

简单会话保持中一个很重要的参数就是连接超时值,负载均衡器会为每一个处于保持状态中的会话设定一个时间值。若一个会话从上一次完成到下次再来之间的间隔时间小于超时值时,负载均衡器将会将新的连接进行会话保持;但如果这个间隔大于该超时值,负载均衡器会将新来的连接认为是新的会话然后进行负载平衡。

简单会话保持实现简单,只需要根据数据包三、四层的信息就可以实现,效率比较高。

但此种方式存在的问题就在于,当多个客户端通过代理或地址转换的方式访问服务器时,由于来源地址一样,请求都被分配到同一台服务器上,会导致服务器之间的负载严重失衡。

另外一种情况是,同一个客户端产生大量并发,要求分配到多个服务器上处理的同时进行会话保持。这时基于客户端源地址的会话保持方法也会导致负载均衡失效。

以上情况出现时,就必须要考虑使用其他的会话保持方式。

4.2. 存会话(Session)的会话保持

此种方式通过多个后端服务器共享 Session 的方式,实现与负载均衡同时的会话保持。主要有以下几种形式:

1) 数据库存放

Session 信息存储到数据库表以实现不同应用服务器间 Session 信息的共享。此种方式适合数据库访问量不大的网站。

  • 优点:实现简单
  • 缺点:由于数据库服务器相对于应用服务器更难扩展且资源更为宝贵,在高并发的 Web 应用中,最大的性能瓶颈通常出现在数据库服务器。因此如果将 Session 存储到数据库表,频繁的数据库操作会影响业务。

2) 文件系统存放

通过文件系统(比如NFS)来实现各台服务器间的 Session 共享。此种方式适合并发量不大的网站。

  • 优点:各台服务器只需要 mount 存储 Session 的磁盘即可,实现较为简单。
  • 缺点:NFS 对高并发读写的性能并不高,在硬盘 I/O 性能和网络带宽上存在较大瓶颈,尤其是对于 Session 这样的小文件的频繁读写操作。

3) Memcached 存放

利用 Memcached 来保存 Session 数据,直接通过内存的方式读取。

  • 优点:效率高,在读写速度上会比存放在文件系统时快很多,而且多个服务器共用 Session 也更加方便,将这些服务器都配置成使用同一组 memcached 服务器就可以,减少了额外的工作量。
  • 缺点:一旦宕机内存中的数据将会丢失,但对 Session 数据来说并不是严重的问题。如果网站访问量太大、Session 太多的时候 memcached 会将不常用的部分删除,但是如果用户隔离了一段时间之后继续使用,将会发生读取失败的问题。

4.3. 基于cookie的会话保持(七层会话保持)

基于cookie的会话保持可使用植入 cookie 和重写 cookie 来进行会话保持。

4.3.1. 植入 cookie 是什么?

植入 cookie 是指由负载均衡服务器来给客户端设置 cookie,即 HTTP/HTTPS 响应报文中插入 SERVERID 字串和客户配置时指定的超时时间,在此时间内会将同一客户端的请求传入到同一个后端 KEC 服务器,当客户端浏览器再次通过此 cookie 访问时,负载均衡不会传给后端的 KEC 服务器,即插入 cookie 关键字与值对后端 KEC 来说是完全不需要知道的。

4.3.2.重写 cookie 是什么?

重写 cookie 是指负载均衡实例的拥有者可以按照自己的需要自定义在后端的 KEC 服务器回复 HTTP/HTTPS 响应中插入 cookie 关键字与值,后端的 KEC 服务器上同时需要维护此 cookie 的超时时间与生存时间,在此响应报文经过负载均衡时,负载均衡会基于一定规则重写 cookie 的值字串用于会话保持,当携带 cookie 关键字与值的请求到来时会将此 cookie 关键字与值传入到初始插入 cookie 的后端 KEC 服务器;但 cookie 值的内容已经与初始相比已经改变。

金山云 SLB 的7层会话保持能力,可以选择重写 cookie 或者植入 cookie 的方式实现。

金山云,开启您的云计算之旅

免费注册