nginx:负载均衡的session共享
一、场景
当nginx做了负载均衡之后，同一个ip的url请求服务器的时候，负载均衡会根据每台服务器的权重等一些设置将请求转发到不同的服务器上去进行处理，这样的话针对一些带有状态请求的情况来说就是个很大的问题，因为是带有状态的请求就好比登陆状态一样，A用户登陆系统，负载均衡机制把A用户的登陆请求分发给了s1服务器，这个时候s1服务器上就会记录A用户登陆的session信息，登陆成功后，当A用户进行相应的操作，比如进入个人中心，这时候这个请求经过反向代理服务器的时候，负载均衡机制根据当前集群中的各个服务器的压力性能等情况可能把请求分发给了s2服务器处理，那么这个时候会去验证用户的状态是否登录，也就是验证session，可是A用户的session保存在了s1服务器上，造成再s2服务器上请求验证状态找不到对应的session，就会认为用户未登录而做的异常操作，就会提醒用户去登录，从而跳转到登录页面，那么这就是负载均衡针对带有状态的请求的一个弊端。
二、解决的方案
1. 不使用session，使用cookie
session是存放在服务器端的，cookie是存放在客户端的，我们可以把用户访问页面产生的session放到cookie里面，就是以cookie为中转站。你访问web服务器A，产生了session然后把它放到cookie里面，当你的请求被分配到B服务器时，服务器B先判断服务器有没有这个session，如果没有，再去看看客户端的cookie里面有没有这个session，如果也没有，说明session真的不存，如果cookie里面有，就把cookie里面的sessoin同步到服务器B，这样就可以实现session的同步了。
说明：这种方法实现起来简单，方便，也不会加大数据库的负担，但是如果客户端把cookie禁掉了的话，那么session就无从同步了，这样会给网站带来损失；cookie的安全性不高，虽然它已经加了密，但是还是可以伪造的，所以这种方式也是不推荐的。
2. session存在数据库mysql
session保存在数据库中，是把session表和其他的数据表存放在一起，那么当用户只要登录后随便操作了些什么就要去数据库验证一下session的状态，这样无疑加重了mysql数据库的压力；如果数据库也做了集群的话，那么也就是说每个数据库集群的节点都得保存这个session表，而且要保证每个集群的节点中数据库的session表的数据保持一致，实时同步
说明：session保持在数据库，加重了数据库的IO，增大数据库的压力和负担，从而影响数据库的读写性能，而且mysql集群的话也不利于session的实时同步
3. session存在缓存memcache或者redis中
memcache可以做分布式，php配置文件中设置存储方式为memcache，这样php自己会建立一个session集群，将session数据存储在memcache中。
说明：这种方式来同步session，不会加大数据库的负担，而且安全性比用cookie保存session大大的提高，把session放到内存里面，比从文件中读取要快很多。但是memcache把内存分成很多种规格的存储块，有块就有大小，这种方式也就决定了，memcache不能完全利用内存，会产生内存碎片，如果存储块不足，还会产生内存溢出。
4. ip_hash技术，nginx中可以配置，当某个ip下的客户端请求指定（固定，因为根据IP地址计算出一个hash值，根据hash值来判断分配给那台服务器，从而每次该ip请求都分配到指定的服务器）的服务器，这样就可以保证有状态请求的状态的完整性，不至于出现状态丢失的情况，一下是nginx的配置，可以参考一下：
复制代码
upstream nginx.example.com
{
server 192.168.1.2:80;
server 192.168.1.3:80;
ip_hash;
}
server
{
listen 80;
location /
{
proxy_pass
http://nginx.example.com;
}
}
复制代码
注意：ip_hash这个方案确实可以保证带有状态的请求的完整性，但是它有一个很大的缺陷，那就是ip_hash方案必须保证Nginx是最前端的服务器（接受真实的ip），如果nginx不是最前端的服务器，还存在中间件（中间服务器什么的），那么nginx获取的ip地址就不是真实的ip地址，那么这个ip_hash就没有任何意义
5.还有其他的一些方法，本人暂时还不太清楚，有待继续的学习（url_hash不知道可以不可以？是否添加一台共享数据的服务器，把状态等一些公共的数据都保持到这台服务器上，从而集群的所有服务器都从共享服务器上边获取状态进行验证？？待求证）
