负载均衡常见问题之会话保持-粘滞会话（StickySessions）
会话保持是负载均衡最常见的问题之⼀，也是⼀个相对⽐较复杂的问题。
会话保持有时候⼜叫做粘滞会话(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⼤⼩存在限制；安全性；带宽及数据解压缩、⽹络传输性能问题。
nginx和apache区别基于Memcached 存储Session
利⽤Memcached来保存Session数据，直接通过内存的⽅式，效率⾃然能够提⾼不少。 在读写速度上会⽐ files 时快很多，⽽且在多个服务器需要共⽤ session 时会⽐较⽅便，将这些服务器都配置成使⽤同⼀组 memcached 服务器就可以，减少了额外的⼯作量。
缺点： session 数据都保存在 memory 中，⼀旦宕机，数据将会丢失。但对 session 数据来说并不是严重的问题。如果⽹站访问量太⼤，session太多的时候，memcached会将不常⽤的部分删除，但是如果⽤户隔离了⼀段时间之后继续使⽤，已经全部乱套了。