在我们给Web站点使用负载均衡之后，必须面临的一个重要问题就是Session的处理办法，无论是PHP、Python、Ruby还是Java，只要使用服务器保存Session，在做负载均衡时都需要考虑Session的问题。

问题在哪里？如何处理？

• 会话保持（案例：Nginx、Haproxy）
• 会话复制（案例：Tomcat）
• 会话共享（案例：Memcached、Redis）

问题在哪里？

从用户端来解释，就是当一个用户第一次访问被负载均衡代理到后端服务器A并登录后，服务器A上保留了用户的登录信息；当用户再次发送请求时，根据负载均衡策略可能被代理到后端不同的服务器，例如服务器B，由于这台服务器B没有用户的登录信息，所以导致用户需要重新登录。这对用户来说是不可忍受的。所以，在实施负载均衡的时候，我们必须考虑Session的问题。

在负载均衡中，针对Session的处理，我们一般有以下几种方法：

• Session 保持
• Session 复制
• Session 共享

会话保持

Session保持（会话保持）是我们见到最多的名词之一，通过会话保持，负载均衡进行请求分发的时候保证每个客户端固定的访问到后端的同一台应用服务器。会话保持方案在所有的负载均衡都有对应的实现。而且这是在负载均衡这一层就可以解决Session问题。

nginx 做负载均衡的session保持

对于Nginx可以选用Session保持的方法实行负载均衡，nginx的upstream目前支持5种方式的分配方式，其中有两种比较通用的Session解决方法，ip_hash和url_hash。注意：后者不是官方模块，需要额外安装。

 IP_HASH

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，达到了Session保持的方法。

例：

upstream bakend {
   ip_hash;
   server192.168.100.10:80;
   server192.168.100.20:80;
 }

Haproxy做负载均衡的Session保持

Haproxy作为一个优秀的反向代理和负载均衡软件，也提供了多种Session保持的方法，下面列举了两种最常用的：

源地址 Hash

haroxy 将用户IP经过hash计算后指定到固定的真实服务器上（类似于nginx 的ip hash 指令）

配置指令:balancesource

使用cookie 进行识别

也就是Haproxy在用户第一次访问的后在用户浏览器插入了一个Cookie，用户下一次访问的时候浏览器就会带上这个Cookie给Haproxy，Haproxy进行识别。

配置指令:cookie  SESSION_COOKIE  insert indirect nocache

配置例子如下：

cookie SERVERID insert indirect nocache

server web01 192.168.100.10:8080 check cookie web01

server web02 192.168.100.20:8080 check cookie web02

会话保持的缺点：

会话保持看似解决了Session同步的问题，但是却带来的一些其它方面的问题：

负载不均衡了：由于使用了Session保持，很显然就无法保证负载绝对的均衡。

没有彻底解决问题：如果后端有服务器宕机，那么这台服务器的Session丢失，被分配到这台服务请求的用户还是需要重新登录。

会话复制

既然，我们的目标是所有服务器上都要保持用户的Session，那么将每个应用服务器中的Session信息复制到其它服务器节点上是不是就可以呢？这就是Session的第二中处理办法：会话复制。

会话复制在Tomcat上得到了支持，它是基于IP组播（multicast）来完成Session的复制，Tomcat的会话复制分为两种：

全局会话复制：利用Delta Manager复制会话中的变更信息到集群中的所有其他节点。

非全局复制：使用Backup Manager进行复制，它会把Session复制给一个指定的备份节点。

不过，这里我不准备来解释会话复制的Tomcat配置，如果有需求可以参考Tomcat官方文档，主要是因为会话复制不适合大的集群。根据笔者在生产的实践案例，当时是在集群超过6个节点之后就会出现各种问题，不推荐生产使用。

会话共享

既然会话保持和会话复制都不完美，那么我们为什么不把Session放在一个统一的地方呢，这样集群中的所有节点都在一个地方进行Session的存取就可以解决问题。

Session存放到哪里？

对于Session来说，肯定是频繁使用的，虽然你可以把它存放在数据库中，但是真正生产环境中我更推荐存放在性能更快的分布式KV数据中，例如：Memcached和Redis或者NFS中。

PHP设置SESSION共享

如果你使用的是PHP那么恭喜你，配置非常的简单。PHP通过两行配置就可以把Session存放在Memcached或者Redis中，当然你要提前配置好他们。修改php.ini：

使用Memcache存储Session

session.save_handler = memcache

session.save_path = "tcp://192.168.100.10:11211"

使用Redis存储Session

session.save_handler = redis

session.save_path ="tcp://localhost:6379"

提醒：别忘了给PHP安装memcache或者redis插件。

Django设置Session共享

在Django中Session是通过一个中间件管理的。如果要在应用程序中使用Session，需要在settings.py中的MIDDLEWARE_CLASSES变量中加入’django.contrib.sessions.middleware.SessionMiddleware’ 。Django的Session引擎可以将Session存放在三个地方，分别是：数据库、缓存、文件。

使用数据库保存Session

如果你想使用数据库支持的会话，建议使用内存表Heap，提高session操作的读写效率。你需要添加’django.contrib.sessions’到你的INSTALLED_APPS设置中。在配置完成之后，请运行manage.py migrate来安装保存会话数据的一张数据库表。

它的缺点在于session的并发读写能力取决于Mysql数据库的性能，同时需要自己实现session淘汰逻辑，以便定时从数据表中更新、删除 session记录，当并发过高时容易出现表锁，虽然我们可以选择行级锁的表引擎，但不得不否认使用数据库存储Session还是有些杀鸡用牛刀的架势。

基于NFS的Session共享

NFS是Net FileSystem的简称，最早由Sun公司为解决Unix网络主机间的目录共享而研发。

这个方案实现最为简单，无需做过多的二次开发，仅需将共享目录服务器mount到各频道服务器的本地session目录即可，缺点是NFS依托于复杂的安全机制和文件系统，因此并发效率不高，尤其对于session这类高并发读写的小文件，会由于共享目录服务器的io-wait过高，最终拖累前端WEB应用程序的执行效率。

基于Memcache的Session共享

Memcache由于是一款基于Libevent多路异步I/O技术的内存共享系统，简单的Key + Value数据存储模式使得代码逻辑小巧高效，因此在并发处理能力上占据了绝对优势，目前本人所经历的项目达到2000/秒 平均查询，并且服务器CPU消耗依然不到10%。

另外值得一提的是Memcache的内存hash表所特有的Expires数据过期淘汰机制，正好和Session的过期机制不谋而合，降低了过期Session数据删除的代码复杂度，对比“基于数据库的存储方案”，仅这块逻辑就给数据表产生巨大的查询压力。

使用缓存保持Session

对于简单的缓存会话：

可以设置SESSION_ENGINE 为”django.contrib.sessions.backends.cache”。此时会话数据将直接存储在你的缓存中。然而，缓存数据将可能不会持久：如果缓存填满或者缓存服务器重启，缓存数据可能会被清理掉。

若要持久的缓存数据：

可以设置SESSION_ENGINE为”django.contrib.sessions.backends.cached_db”。它的写操作使用缓存，对缓存的每次写入都将再写入到数据库。对于读取的会话，如果数据不在缓存中，则从数据库读取。两种会话的存储都非常快，但是简单的缓存更快，因为它放弃了持久性。大部分情况下，cached_db后端已经足够快，但是如果你需要榨干最后一点的性能，并且接受会话数据丢失的风险，那么你可使用cache而不是cached_db

使用文件保存Session

使用文件保存Session不再我们的讨论之类，因为很难进行共享，PHP默认也是将Session存放在/tmp目录下。

总结如下：

会话保持的缺点： ①负载不均衡了 ②没有彻底解决问题

会话复制的缺点： 集群超过6个节点就会出现一系列的问题

会话共享：会话数据共享在Nosql（Redis）数据库中分享。

session + redis 实现session 共享原理和原因

要用  session  + redis 共享session的原因：

先进的企业级或者大型的网站平台，都是分布式结构，分布式的好处是通过nginx分发请求，让多个服务器各自处理请求，来减少单一服务器的压力，并且提高执行效率。

在这个分布式结构下，如果不用共享session的话，就会出现问题。当一个客户端发送一个请求（无session），通过nginx将第一次请求分发给服务器1，服务器判断无session，就让那个客户进行登录操作，并得到响应，此时客户端会存储一个来自服务器1响应的session，并存储在客户端。

当客户端发送第二次请求的时候，此时本次请求已经携带了session（跳过登录），nginx却将请求分发给服务器2，因为服务器2中没有session，所以无法与客户端session进行对应。所以程序会出现异常或是报错，无法正常响应。

解决方法 ： session  +  redis 实现session 共享

  session  +  redis 实现session 共享原理：

为了避免上面session 在服务器直接不共享的问题，就将 session 放入 redis 中。

当客户端第一次发送请求后，nginx将请求分发给服务器1 ，然后将服务器1 产生的session 放入redis中，这样的话 客户端、服务器1 和redis中都会有一个相同的session，当客户端发送第二次请求的时候，nginx将请求分发给服务器2 （已知服务器2 中无session），因为客户端自己携带了一个session，那么服务器2 就可以拿着客户端带来的cookie中的session ID去redis中获取session，只要拿到这个session，就能执行之后的操作。