应用负载均衡回源与会话

背景

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

stickysessions：

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

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

如果用户需要登录，那么就可以简单的理解为会话，如果不需要登录就是连接。

会话保持机制与负载均衡的功能是矛盾的。负载均衡希望将来自客户端的连接、请求均衡的转发至后端的多台服务器，以避免单台服务器负载过高。

而会话保持机制却要求将某些请求转发至同一台服务器进行处理。因此，在实际的部署环境中，我们要根据应用环境的特点，选择适当的会话保持机制。

回源的几种方式

回源最短时间选择
地理位置选择
ip哈希
轮询、随机

原始负载均衡的基本原理

对于同一个连接中的数据包，负载均衡会将其进行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等。

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

使用数据库存放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大小存在限制；安全性；带宽及数据解压缩、网络传输性能问题。