Nginx的负载均衡及碰到的问题

测试环境:lnmp

本节就聊聊采用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配置如何实现负载   

 

vhost  

本机 192.168.60.128:80

129.test.com.conf

 

 upstream  129.test.com {
     ip_hash;
        server   192.168.60.128:1818 weight=20 down;
          server   192.168.60.129 weight=10 max_fails=3 fail_timeout=30s up;
     }


       server {
        listen       80;
        server_name  129.test.com;
        access_log /home/wwwlogs/129.test.com.access.log access; 
        location / 
        {
           proxy_pass  http://129.test.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; } }

负载服务器1-192.168.60.128:1818

1818.129.test.com.conf

server
        {
                listen 1818;
                #listen [::]:80 default ipv6only=on;
                server_name 129.test.com;
                index index.html index.htm index.php;
                root  /home/wwwroot/test;

                #error_page   404   /404.html;
                location ~ [^/]\.php(/|$)
                        {
                                # comment try_files $uri =404; to enable pathinfo
                                try_files $uri =404;
                                fastcgi_pass  unix:/tmp/php-cgi.sock;
                                fastcgi_index index.php;
                                include fastcgi.conf;
                                #include pathinfo.conf;
                        }

                location /nginx_status {
                        stub_status on;
                        access_log   off;
                }

    location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
                        {
                                expires      30d;
                        }

                location ~ .*\.(js|css)?$
                        {
                                expires      12h;
                        }

                access_log  /home/wwwlogs/access.log  access;
        }

负载服务器2-192.168.60.129:80

129.test.com.conf

server
    {
        listen 80;
        #listen [::]:80 default_server ipv6only=on;
        server_name 129.test.com;
        index index.html index.htm index.php;
        root  /home/wwwroot/test2;

        #error_page   404   /404.html;
        include enable-php.conf;

        location /nginx_status
        {
            stub_status on;
            access_log   off;
        }

        location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
        {
            expires      30d;
        }

        location ~ .*\.(js|css)?$
        {
            expires      12h;
        }

        location ~ /\.
        {
            deny all;
        }

        access_log  /home/wwwlogs/access.log;
    }

 

 

当有请求到129.test.com时请求会被分发到对应的upstream设置的服务器列表上。

根据服务器的本身的性能差别及职能,可以设置不同的参数控制。

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.创建mysql表和上传文件保存到mysql数据库

$con = mysql_connect("localhost", "", "");
 mysql_select_db("w3m");
 $sql = "CREATE TABLE updfiles ("
   . " id INTEGER NOT NULL AUTO_INCREMENT"
   . ", name VARCHAR(80) NOT NULL"
   . ", type VARCHAR(80) NOT NULL"
   . ", size INTEGER NOT NULL"
   . ", content BLOB"
   . ", PRIMARY KEY (id)"
   . ")";
 mysql_query($sql, $con);
 mysql_close($con);

2.上传文件并保存到mysql

 $con = mysql_connect("localhost", "", "");
 mysql_select_db("w3m");
 $error = $_FILES['w3img']['error'];
 $tmp_name = $_FILES['w3img']['tmp_name'];
 $size = $_FILES['w3img']['size'];
 $name = $_FILES['w3img']['name'];
 $type = $_FILES['w3img']['type'];
 print("\n");
 if ($error == UPLOAD_ERR_OK && $size > 0) {
  $fp = fopen($tmp_name, 'r');
  $content = fread($fp, $size);
  fclose($fp);  
  $content = addslashes($content);
  $sql = "INSERT INTO fyi_files (name, type, size, content)"
   . " VALUES ('$name', '$type', $size, '$content')";
  mysql_query($sql, $con);
  print("File stored.\n");
 } else {
  print("Database Save for upload failed.\n");
 }
 print("\n");
 mysql_close($con);

 

 

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

 

posted on 2016-12-08 18:50  小乔流水人家  阅读(468)  评论(0)    收藏  举报

导航