Nginx的正反向代理和配置文件详解

亮点:nginx负载均衡

简述:
Nginx (“engine x”) 是一个高性能的HTTP和反向代理服务器,也是一个IMAP/POP3/SMTP服务器。并在一个BSD-like 协议下发行,其特点是占有内存少,
并发能力强,事实上nginx的并发能力确实在同类型的网页服务器中表现较好,中国大陆使用nginx网站用户有:百度、京东、新浪、网易、腾讯、淘宝等。

负载均衡的简述:
   多台服务器处于一个内网,而我们要访问这些服务器,中间加一台 反向代理,根据各台服务器的负载,指定访问其中一台。这就叫负载均衡。
  代理服务器来接受外部的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给外部的请求连接的客户端,此时代理
    服务器对外就表现为一个服务器。

作用:大型网站在接受用户请求的时候,这个访问量是巨大的,这个时候他就要设计怎么去分担这些请求压力。按照我们的理解就是搭建一个应用服务器的集群(tomcat)
每个用户请求进来都会按照不同的分发方式去访问相对应的服务器,这个时候负载均衡的实现就达到了。

反向代理和正向代理的区别:

正向代理:

正向代理,代理,他的工作原理就像一个跳板,
简单的说,
我是一个用户,我访问不了某网站,但是我能访问一个代理服务器
这个代理服务器呢,他能访问那个我不能访问的网站
于是我先连上代理服务器,告诉他我需要那个无法访问网站的内容
代理服务器去取回来,然后返回给我,这个时候我们用户取回的东西还是直接的最终服务端口。

反向代理:
(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet
上请求连接的客户端,此时代理服务器对外就表现为一个反向代理服务器。

继续举例:
例用户访问 http://ooxx.me/readme
但ooxx.me上并不存在readme页面
他是偷偷从另外一台服务器上取回来,然后作为自己的内容吐给用户

但用户并不知情
这很正常,用户一般都很笨

这里所提到的 ooxx.me 这个域名对应的服务器就设置了反向代理功能

结论就是 反向代理正好相反,对于客户端而言它就像是原始服务器,并
且客户端不需要进行任何特别的设置。客户端向反向代理 的命名空间(name-space)
中的内容发送普通请求,接着反向代理将判断向何处(原始服务器)转交请求,
并将获得的内容返回给客户端,就像这些内容 原本就是它自己的一样。这个时候的
用户请求不知道访问的是哪里,用户其实是很笨的,在这里只是发送了请求而已。

配置项:
1、轮询         
        轮询是upstream的默认分配方式,即每个请求按照时间顺序轮流分配到不同的后端服务器,如果某个后端服务器down掉后,能自动剔除。
        upstream backend {
            server 192.168.1.101:8888;
            server 192.168.1.102:8888;
            server 192.168.1.103:8888;
        }
2、weight        
        轮询的加强版,即可以指定轮询比率,weight和访问几率成正比,主要应用于后端服务器异质的场景下。
        upstream backend {
            server 192.168.1.101 weight=1;
            server 192.168.1.102 weight=2;
            server 192.168.1.103 weight=3;
        }
3、ip_hash        
        每个请求按照访问ip(即Nginx的前置服务器或者客户端IP)的hash结果分配,这样每个访客会固定访问一个后端服务器,可以解决session一致问题。
        upstream backend {
             ip_hash;
            server 192.168.1.101:7777;
            server 192.168.1.102:8888;
            server 192.168.1.103:9999;
        }
4、fair        
        fair顾名思义,公平地按照后端服务器的响应时间(rt)来分配请求,响应时间短即rt小的后端服务器优先分配请求。
        upstream backend {
            server 192.168.1.101;
            server 192.168.1.102;
            server 192.168.1.103;
             fair;
        }
5、url_hash
        与ip_hash类似,但是按照访问url的hash结果来分配请求,使得每个url定向到同一个后端服务器,主要应用于后端服务器为缓存时的场景下。
        upstream backend {
            server 192.168.1.101;
            server 192.168.1.102;
            server 192.168.1.103;
             hash $request_uri;
             hash_method crc32;
        }
         其中,hash_method为使用的hash算法,需要注意的是:此时,server语句中不能加weight等参数。
         关于,如何在负载均衡中使用upstream请参看这里。

具体nginx.conf配置说明:

########### 每个指令必须有分号结束。#################
#user administrator administrators;  #配置用户或者组,默认为nobody nobody。
#worker_processes 2;  #允许生成的进程数,默认为1
#pid /nginx/pid/nginx.pid;   #指定nginx进程运行文件存放地址
error_log log/error.log debug;  #制定日志路径,级别。这个设置可以放入全局块,http块,server块,级别以此为:debug|info|notice|warn|error|crit|alert|emerg
events {
    accept_mutex on;   #设置网路连接序列化,防止惊群现象发生,默认为on
    multi_accept on;  #设置一个进程是否同时接受多个网络连接,默认为off
    #use epoll;      #事件驱动模型,select|poll|kqueue|epoll|resig|/dev/poll|eventport
    worker_connections  1024;    #最大连接数,默认为512
}
http {
    include       mime.types;   #文件扩展名与文件类型映射表
    default_type  application/octet-stream; #默认文件类型,默认为text/plain
    #access_log off; #取消服务日志    
    log_format myFormat ‘$remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for’; #自定义格式
    access_log log/access.log myFormat;  #combined为日志格式的默认值
    sendfile on;   #允许sendfile方式传输文件,默认为off,可以在http块,server块,location块。
    sendfile_max_chunk 100k;  #每个进程每次调用传输数量不能大于设定的值,默认为0,即不设上限。
    keepalive_timeout 65;  #连接超时时间,默认为75s,可以在http,server,location块。

    upstream mysvr {   
      server 127.0.0.1:7878;
      server 192.168.10.121:3333 backup;  #热备
    }
    error_page 404 https://www.baidu.com; #错误页
    server {
        keepalive_requests 120; #单连接请求上限次数。
        listen       4545;   #监听端口
        server_name  127.0.0.1;   #监听地址       
        location  ~*^.+$ {       #请求的url过滤,正则匹配,~为区分大小写,~*为不区分大小写。
           #root path;  #根目录
           #index vv.txt;  #设置默认页
           proxy_pass  http://mysvr;  #请求转向mysvr 定义的服务器列表
           deny 127.0.0.1;  #拒绝的ip
           allow 172.18.5.54; #允许的ip           
        } 
    }
}

项目应用描述:
我们发现我们云平台停车这个项目部署之后,发现用户访问量增加了很多,这个时候我们的服务器就承载不了了,所以我们公司提出的解决方案就是搭建一个tomcat+Nginx的应用服务器的集群
这么搭建的好好处就是我们的用户请求进来之后我们可以通过nginx的反向代理服务器来分配用户的请求去访问哪些tomcat服务器,我们在项目中应用的分配策略采是fair(第三方),
为什么要用这种呢,因为这种是现在nginx常用的分配策略,好处是他能接受请求之后选择出响应时间最快的服务器来进行响应,这样能尽快的回复用户的请求。
Ip_hash和url_hash我没具体研究过,还有就是为什么不选用轮询和权重。先来说不选用轮询,因为轮询是最基本的nginx分配策略,这种策略我觉的还是不太合理,如果其中几台服务器响应慢,还是影响了
访问速度,选用第二种权重的话,如果权重大的服务器用的多的话,其他的服务器反而没有更大程度的利用起来。

权重:举个例子
upstream mysvr {   
      server tomcat1 weight=1   1
      server tomcat2 weight=2   2,3
      server tomcat3 weight=3   4,5,6
    }
在这个时候,她会把这些数字123加起来,等于6,然后随机多少个访问,比如是25个,然后25%6+1,得到的数去访问(1)(2,3)(4,5,6)

本文来自投稿,不代表Linux运维部落立场,如若转载,请注明出处:http://www.178linux.com/102470

发表评论

登录后才能评论

This site uses Akismet to reduce spam. Learn how your comment data is processed.

联系我们

400-080-6560

在线咨询:点击这里给我发消息

邮件:1823388528@qq.com

工作时间:周一至周五,9:30-18:30,节假日同时也值班