针对负载均衡集群中的session解决方案的总结

 

在平常运维工做中，当给Web站点使用负载均衡以后，必须面临的一个重要问题就是Session的处理办法，不管是PHP、Python、Ruby仍是Java语言环境，只要使用服务器保存Session，在作负载均衡时都须要考虑Session的问题。

一般面临的问题

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

在负载均衡中，针对Session的处理，通常有如下几种方法：
1）Session会话保持（案例：Nginx、Haproxy）
2）Session会话复制（案例：Tomcat）
3）Session会话共享（案例：Memcached、Redis）

 1、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.0.11:80;
   server192.168.0.12:80;
 }

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

1) 源地址 Hash
haroxy 将用户IP通过hash计算后指定到固定的真实服务器上（相似于nginx 的ip hash 指令）
配置指令:balancesource

2)使用cookie 进行识别
也就是Haproxy在用户第一次访问的后在用户浏览器插入了一个Cookie，用户下一次访问的时候浏览器就会带上这个Cookie给Haproxy，Haproxy进行识别。
配置指令:cookie  SESSION_COOKIE  insert indirect nocache

配置例子以下：
cookie SERVERID insert indirect nocache
server web01 192.168.56.11:8080 check cookie web01
server web02 192.168.56.12:8080 check cookie web02

===========================================================
会话保持的缺点：
1) 会话保持看似解决了Session同步的问题，可是却带来的一些其它方面的问题：
2）负载不均衡了：因为使用了Session保持，很显然就没法保证负载绝对的均衡。
3）没有完全解决问题：若是后端有服务器宕机，那么这台服务器的Session丢失，被分配到这台服务请求的用户仍是须要从新登陆。

2、Session会话保持

既然，咱们的目标是全部服务器上都要保持用户的Session，那么将每一个应用服务器中的Session信息复制到其它服务器节点上是否是就能够呢？
这就是Session的第二中处理办法：会话复制。

会话复制在Tomcat上获得了支持，它是基于IP组播（multicast）来完成Session的复制，Tomcat的会话复制分为两种：
1）全局会话复制：利用Delta Manager复制会话中的变动信息到集群中的全部其余节点。
2）非全局复制：使用Backup Manager进行复制，它会把Session复制给一个指定的备份节点。

不过，这里不许备来解释会话复制的Tomcat配置，若是有需求能够参考Tomcat官方文档，主要是由于会话复制不适合大的集群。根据生产的实践案例，
在集群超过6个节点以后就会出现各类问题，不推荐生产使用。

 3、Session会话共享

既然会话保持和会话复制都不完美，那么咱们为何不把Session放在一个统一的地方呢，这样集群中的全部节点都在一个地方进行Session的存取就能够解决问题。
=========================================================================================
Session存放到哪里？
对于Session来讲，确定是频繁使用的，虽然你能够把它存放在数据库中，可是真正生产环境中我更推荐存放在性能更快的分布式KV数据中，
例如：Memcached和Redis。
---------------------------------------------------------------
PHP设置Session共享
若是使用的是PHP那么恭喜你，配置很是的简单。PHP经过两行配置就能够把Session存放在Memcached或者Redis中，固然你要提早配置好他们。修改php.ini：

使用Memcache存储Session
session.save_handler = memcache
session.save_path = "tcp://192.168.56.11:11211"

使用Redis存储Session
session.save_handler = redis
session.save_path ="tcp://localhost:6379"

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

---------------------------------------------------------------
Tomcat设置Session共享
可使用MSM（Memcached Session Manager）来实现一样把Session存放到Memcache中。

---------------------------------------------------------------
Django设置Session共享
在Django中Session是经过一个中间件管理的。若是要在应用程序中使用Session，须要在settings.py中的MIDDLEWARE_CLASSES变量中加入
'django.contrib.sessions.middleware.SessionMiddleware' 。Django的Session引擎能够将Session存放在三个地方，分别是：数据库、缓存、文件。

---------------------------------------------------------------
若是你想使用数据库支持的会话，你须要添加’django.contrib.sessions’到你的INSTALLED_APPS设置中。在配置完成以后，请运行manage.py migrate
来安装保存会话数据的一张数据库表。

---------------------------------------------------------------
使用缓存保持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）数据库中分享。