Nginx的负载均衡的那点事

https://www.cnblogs.com/mecity/archive/2011/06/20/2085529.html
本节就聊聊采用Nginx负载均衡之后碰到的问题：
Session问题
文件上传下载
通常解决服务器负载问题，都会通过多服务器分载来解决。常见的解决方案有：
网站入口通过分站链接负载（天空软件站，华军软件园等）
DNS轮询
F5物理设备
Nginx等轻量级架构
那我们看看Nginx是如何实现负载均衡的，Nginx的upstream目前支持以下几种方式的分配
1、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
2、weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
2、ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
3、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
4、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的负载均衡的简单配置。那继续我们的本节讨论内容：
一、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论坛。缓存实现的小范围分布式也是比较常用的，比如单点登录也是一种特殊情况。
二、文件上传下载
如果实现了负载均衡，除了Session问题，我们还会碰到文件的上传下载问题。文件不可能上传不同的服务器上，这样会导致下载不到对应文件的问题。我们看一下下面的方案
独立文件服务器 
文件压缩数据库
两种方案都是常用的，我们来说一下文件压缩数据库，以前的方式都是将文件二进制压缩至关系型数据库，而现在NOSQL的流行，加上MongoDB处理文件又比较方便，所以文件压库又多了一种选择。毕竟文件服务器的效率和管理以及安全都不及数据库。
随便聊聊这点事，其实也就是一些应用的趋势和多一种解决方案的实现。
-------------------------------------------------------------------------------------
各个参数的作用：

设备的状态有: 
1.down 表示单前的server暂时不参与负载 
2.weight 权重,默认为1。 weight越大，负载的权重就越大。 
3.max_fails 允许请求失败的次数默认为1。当超过最大次数时，返回proxy_next_upstream
模块定义的错误 
4.fail_timeout max_fails次失败后，暂停的时间。 
5.backup 备用服务器,
其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。
------------------------------------------------------------
文件同步：
https://bbs.aliyun.com/read/245721.html?pos=3
利用Rsync服务SLB下多台centos服务器网站文件同步更新https://bbs.aliyun.com/read/245376.html?spm=5176.bbsr245721.0.0.7wSApo
https://bbs.aliyun.com/read/118907.html?spm=0.0.0.0.1NyO2B
http://blog.csdn.net/echobar/article/details/53863923
--------------------------------------------------------------------------
用SLB和用nginx自己弄区别在哪https://bbs.aliyun.com/read/299397.html?page=e