一、分布式Session共享方案的由来
客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上，这就是 Session。客户端浏览器再次访问时只需要从该 Session 中查找该客户的状态就可以了。
在实际工作中我们建议使用外部的缓存设备来共享 Session，避免单个服务器节点挂掉而影响服务，共享数据都会放到外部缓存容器中。
使用Redis实现共享session，所有服务器的session信息都存储到了同一个Redis集群中，即所有的服务都将 Session 的信息存储到 Redis 集群中，无论是对 Session 的注销、更新都会同步到集群中，达到了 Session 共享的目的。
Cookie是服务器写给客户端的文件，也可以称为浏览器缓存。保存在客户端浏览器中，而 Session 保存在服务器上。
二、常见的session集群方案
传统的session由服务器端生成并存储，当应用进行分布式集群部署的时候，如何保证不同服务器上session信息能够共享呢？
两种实现方式：
1.不同服务器上session数据进行复制
2.session集中存储(session共享)（redis，memcached，hbase等）
两种方式的优缺点，一目了然.
- Session复制
是指session信息会在集群节点之间复制，每个节点服务器上都会有相同的session信息。
优点: 是即使一个节点服务器宕机了，只要还有服务器存活，就不影响用户使用。
缺点: 缺点是node节点之间通信频繁，响应速度有影响，多并发、高频操作的情况下性能下降比较厉害。
- Session共享
基于Memcache/Redis等数据库的session共享。
tomcat自带集群中，提供了session复制，session信息会在各个tomcat中同步，对网络要求较高，session内存消耗影响会很大,对于小集群够用了，大集群还是建议使用redis或者memcache进行session共享。
因此，构建tomcat集群时，可以使用tomcat基于redis的session共享机制。而在通过nginx构建集群时，也涉及session的问题.如下图所示架构:
在nginx的集群架构下,可根据设置的nginx负载均衡算法的不同，session的实现机制也不相同，例如轮询（默认），指定权重，fair（第三方），url_hash（第三方）负载算法时，集群各个节点之间必须通过session共享来实现。
要避开session问题,可以使用nginx的ip_hash算法，此算法将用户的请求统一发送到同一个节点服务器上，如不考虑节点服务器宕机的情况，可不考虑session问题。但是，节点服务器宕机后，用户需要关掉浏览器从新打开登录才能恢复正常，这样体验会变得很差。因此，session共享在集群架构中有很大的用途。
发表回复