从用户端来阐明，便是当一个用户第一次访问被负载均衡代理到后端做事器A并登录后，做事器A上保留了用户的登录信息；当用户再次发送要求时，
根据负载均衡策略可能被代理到后端不同的做事器，例如做事器B，由于这台做事器B没有用户的登录信息，以是导致用户须要重新登录。这对用户
来说是不可忍受的。以是，在履行负载均衡的时候，我们必须考虑Session的问题。
在负载均衡中，针对Session的处理，一样平常有以下几种方法：
1）Session会话保持（案例：Nginx、Haproxy）2）Session会话复制（案例：Tomcat）3）Session会话共享（案例：Memcached、Redis）
一、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) 源地址 Hashharoxy 将用户IP经由hash打算后指定到固定的真实做事器上（类似于nginx 的ip hash 指令）配置指令:balancesource 2)利用cookie 进行识别也便是Haproxy在用户第一次访问的后在用户浏览器插入了一个Cookie，用户下一次访问的时候浏览器就会带上这个Cookie给Haproxy，Haproxy进行识别。配置指令:cookie SESSION_COOKIE insert indirect nocache
配置例子如下：
cookie SERVERID insert indirect nocacheserver web01 192.168.56.11:8080 check cookie web01server web02 192.168.56.12:8080 check cookie web02
会话保持的缺陷：
1) 会话保持看似办理了Session同步的问题，但是却带来的一些其它方面的问题：2）负载不屈衡了：由于利用了Session保持，很显然就无法担保负载绝对的均衡。3）没有彻底办理问题：如果后端有做事器宕机，那么这台做事器的Session丢失，被分配到这台做事要求的用户还是须要重新登录。
二、Session会话保持
既然，我们的目标是所有做事器上都要保持用户的Session，那么将每个运用做事器中的Session信息复制到其它做事器节点上是不是就可以呢？
这便是Session的第二中处理办法：会话复制。
会话复制在Tomcat上得到了支持，它是基于IP组播（multicast）来完成Session的复制，Tomcat的会话复制分为两种：
1）全局会话复制：利用Delta Manager复制会话中的变更信息到集群中的所有其他节点。2）非全局复制：利用Backup Manager进行复制，它会把Session复制给一个指定的备份节点。
不过，这里不准备来阐明会话复制的Tomcat配置，如果有需求可以参考Tomcat官方文档，紧张是由于会话复制不适宜大的集群。根据生产的实践案例，
在集群超过6个节点之后就会涌现各种问题，不推举生产利用。
三、Session会话共享
既然会话保持和会话复制都不完美，那么我们为什么不把Session放在一个统一的地方呢，这样集群中的所有节点都在一个地方进行Session的Session存放到哪里？对付Session来说，肯定是频繁利用的，虽然你可以把它存放在数据库中，但是真正生产环境中我更推举存放在性能更快的分布式KV数据中，例如：Memcached和Redis。
PHP设置Session共享
如果利用的是PHP那么恭喜你，配置非常的大略。PHP通过两行配置就可以把Session存放在Memcached或者Redis中，当然你要提前配置好他们。修正php.ini：
利用Memcache存储Session
session.save_handler = memcachesession.save_path = \"大众tcp://192.168.56.11:11211\"大众
利用Redis存储Session
session.save_handler = redissession.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不再我们的谈论之类，由于很难进行共享，PHP默认也是将Session存放在/tmp目录下。
大略总结：
会话保持的缺陷：负载不屈衡;没有彻底办理问题.
会话复制的缺陷：集群超过6个节点就会涌现一系列的问题.
会话共享：会话数据共享在Nosql（Redis）数据库等分享。
