Linux负载均衡粘滞会话：IP_HASH Session(nosql mysql 文件共享系统 ) Cookie客户端加密识别用户

1.IP_HASH

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session 的问题。

    upstream bakend {
        ip_hash;
        server 192.168.0.14:88;
        server 192.168.0.15:80;
    }

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

如果使用硬件作为负载均衡设备，如果遇到一些特殊的情况，需要进行个性化定制，其实是非常有难度和挑战的，再更加多的时间，其实这是根本走不通的，如果使用软件，比如Nginx或者Apache，我们可以对它进行一定程度上的订制，尽可能多的满足业务要求。

2.存储SESSION

2.1基于Redis Memcached 存储Session 

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

2.2使用数据库存放session

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

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

优点：实现简单 

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

2.3使用文件系统存放session

通过文件系统（比如NFS方式）来实现各台服务器间的Session共享，各台服务器只需要mount共享服务器的存储Session的磁盘即可，实现较为简单。但NFS 对高并发读写的性能并不高，在硬盘I/O性能和网络带宽上存在较大瓶颈，尤其是对于Session这样的小文件的频繁读写操作。 适合并发量不大的网站.

3.COOKIE识别

3.1基于浏览器Cookie的Session共享：用户识别使用加密的cookie 

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