nginx 负载均衡分配

本节就聊聊采用Nginx负载均衡以后碰到的问题：

• Session问题

• 文件上传下载

一般解决服务器负载问题，都会经过多服务器分载来解决。常见的解决方案有：

• 网站入口经过分站连接负载（天空软件站，华军软件园等）

• DNS轮询

• F5物理设备

• Nginx等轻量级架构

那咱们看看Nginx是如何实现负载均衡的，Nginx的upstream目前支持如下几种方式的分配
一、轮询（默认）
每一个请求按时间顺序逐一分配到不一样的后端服务器，若是后端服务器down掉，能自动剔除。
二、weight
指定轮询概率，weight和访问比率成正比，用于后端服务器性能不均的状况。
二、ip_hash
每一个请求按访问ip的hash结果分配，这样每一个访客固定访问一个后端服务器，能够解决session的问题。
三、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
四、url_hash（第三方）
按访问url的hash结果来分配请求，使每一个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

Upstream配置如何实现负载   

 http {            upstream  www.test1.com {          ip_hash;          server   172.16.125.76:8066 weight=10;          server   172.16.125.76:8077 down;          server   172.16.0.18:8066 max_fails=3 fail_timeout=30s;          server   172.16.0.18:8077 backup;     }           upstream  www.test2.com {          server   172.16.0.21:8066;          server   192.168.76.98:8066;             }     server {        listen       80;        server_name  www.test1.com;                      location /{           proxy_pass        http://www.test1.com;            proxy_set_header   Host             $host;           proxy_set_header   X-Real-IP        $remote_addr;           proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;        }           }           server {        listen       80;        server_name  www.test2.com;                      location /{           proxy_pass        http://www.test2.com;            proxy_set_header   Host             $host;           proxy_set_header   X-Real-IP        $remote_addr;           proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;     } } 

当有请求到www.test1.com/www.test2.com 时请求会被分发到对应的upstream设置的服务器列表上。test2的每一次请求分发的服务器都是随机的，就是第一种状况列举的。而test1刚是根据来访问ip的hashid来分发到指定的服务器，也就是说该IP的请求都是转到这个指定的服务器上。

根据服务器的自己的性能差异及职能，能够设置不一样的参数控制。

down 表示负载太重或者不参与负载

weight 权重过大表明承担的负载就越大

backup 其它服务器时或down时才会请求backup服务器

max_fails 失败超过指定次数会暂停或请求转往其它服务器

fail_timeout 失败超过指定次数后暂停时间

以上就Nginx的负载均衡的简单配置。那继续咱们的本节讨论内容：

1、Session问题

当咱们肯定一系列负载的服务器后，那咱们的WEB站点会分布到这些服务器上。这个时候若是采用Test2 每一次请求随机访问任何一台服务器上，这样致使你访问A服务器后，下一次请求又忽然转到B服务器上。这个时候与A服务器创建的Session，传到B站点服务器确定是没法正常响应的。咱们看一下经常使用的解决方案：

• Session或凭据缓存到独立的服务器

• Session或凭据保存数据库中

• nginx ip_hash 保持同一IP的请求都是指定到固定的一台服务器

第一种缓存的方式比较理想，缓存的效率也比较高。可是每一台请求服务器都去访问Session会话服务器，那不是加载重了这台Session服务器的负担吗？

第二种保存到数据库中，除了要控制Session的有效期，同时加剧了数据库的负担，因此最终的转变为SQL Server 负载均衡，涉及读，写，过时，同步。

第三种经过nginx ip_hash负载保持对同一服务器的会话，这种看起来最方便，最轻量。

正常状况下架构简单的话， ip_hash能够解决Session问题，可是咱们来看看下面这种状况

这个时候ip_hash 收到的请求都是来自固定IP代理的请求，若是代理IP的负载太高就会致使ip_hash对应的服务器负载压力过大，这样ip_hash就失去了负载均衡的做用了。

若是缓存能够实现同步共享的话，咱们能够经过多session服务器来解决单一负载太重的问题。那Memcached是否能够作Session缓存服务器呢？MemcachedProvider提供了Session的功能，即将Session保存到数据库中。那为何不直接保存到数据库中，而要经过Memcached保存到数据库中呢？很简单，若是直接保存到数据库中，每一次请求Session有效性都要回数据库验证一下。其次，即便咱们为数据库创建一层缓存，那这个缓存也没法实现分布式共享，仍是针对同一台缓存服务器负载太重。网上也看到有用Memcached实现Session缓存的成功案例，固然数据库方式实现的仍是比较经常使用的，好比开源Disuz.net论坛。缓存实现的小范围分布式也是比较经常使用的，好比单点登陆也是一种特殊状况。

2、文件上传下载

若是实现了负载均衡，除了Session问题，咱们还会碰到文件的上传下载问题。文件不可能上传不一样的服务器上，这样会致使下载不到对应文件的问题。咱们看一下下面的方案

• 独立文件服务器 

• 文件压缩数据库

两种方案都是经常使用的，咱们来讲一下文件压缩数据库，之前的方式都是将文件二进制压缩相当系型数据库，而如今NOSQL的流行，加上MongoDB处理文件又比较方便，因此文件压库又多了一种选择。毕竟文件服务器的效率和管理以及安全都不及数据库。

随便聊聊这点事，其实也就是一些应用的趋势和多一种解决方案的实现。