通过Nginx来实现负载均衡技术所带来的Session不同步的处理

题记：在以前的纯网页时代（不能交互），用户只能看看网页信息，可能看见一个想买的物品，只能按照网页上提供的电话、地址来联系。但随着技术的发展，用户可以直接在网站上与人交易，此时会产生一个问题，对方怎么知道一直是你在请求呢，其实是通过Session机制的。

Session机制
客户端第一次请求服务端时，服务端会产生一个session对象（用于保存该客户的信息）；
并且每个session对象，都会有一个唯一的sessionId(用于区分其他session);
服务端又会产生一个cookie,并且该cookie的name=JSESSIONID,value=服务端sessionId的值；
然后服务端会在响应客户端的同时将该cookie发送给客户端，自此客户端就有了一个cookie(JSESSIONID)
因此，客户端的cookie就可以和服务端的session一一对应（JSESSION-sessionID）
（比如：登入淘宝后，一段时间内就不需要再次登入了）
负载均衡
将请求分发的技术，可以是软件诸如Nginx、Apache也可以是硬件诸如F5等。
而负责接收请求处理的服务器的集合就叫做集群。

这个是tomcat集群：
（通过负载均衡技术，可以把http请求分发给不同的服务器处理）

说了这么多，我们上nginx
nginx简介
nginx在中国等发展中国家使用非常多。
优点：安装配置简单、占有内存少、并发处理能力强3W+优化下10w+、
功能强大，动静分离，反向代理。
缺点：支持的应用少（工作在第七层）、不能保持Session。
负载均衡算法

由于nginx不能保持Session同步，所以会导致大问题。

Session不同步带来的问题
假如甲用户发送了一个请求给服务器，服务端做出反应，甲此时的浏览器中就产生了一个cookie(JSESSIONID)，对应的a服务器就会有一个对应的（JSESSION-sessionID）。而甲发送第二个请求给服务器，它通过负载均衡算法可能分配给了b服务器，此时甲携带的cookie(JSESSIONID)在b服务器中找不到对应的
（JSESSION-sessionID）。为了安全，会要求用户重新登入。这样用户每发一个请求就可能会被要求重新登入一次（产生新的session）。用户体验极差。此时就要解决办法了。

Session一致性的解决办法
Stickey Session 粘带Session
Session Replication Session复制
Shared Session Session共享

1,粘带Session

修改Nginx配置文件

upstream balance{
ip_hash;
server 127.0.0.1:8080;
server 127.0.0.1:18080;
}

优点：配置简单、不入侵应用，无额外的代码修改，便于服务器水平拓展。
缺点：服务器重启Session丢失，存在单点负载高的风险，单点故障问题。

2, Session复制

优点：不入侵应用（session序列化）、便于服务器水平拓展、能适应各种负载均衡策略、
服务器重启或宕机不会造成Session丢失。
缺点：性能低、内存消耗、代码考虑（session序列化）
配置：

3, Session共享

使用redis缓存

配置：

优点：能适应各种负载均衡策略、服务器重启或宕机不会造成Session丢失、拓展能力强、适合集群数量大时使用
缺点：对应用有入侵，需增加相关配置、序列化反序列化消耗CPU性能

对比

Session 共享------大型分布式环境首选、可扩展性强、健壮
Session 复制------较小分布式环境首选、无入侵、健壮无单点故障问题
Session IP_HASH —配置简单、无入侵、存在单点故障问题。