nginx全部知识(让你穷光蛋秒变负二代，Come on!)

最新推荐文章于 2020-08-02 13:43:17 发布

wt520it

最新推荐文章于 2020-08-02 13:43:17 发布

阅读量342

点赞数 1

分类专栏： nginx 服务器文章标签： 2018年10月

本文链接：https://blog.csdn.net/wt520it/article/details/83278069

版权

nginx 同时被 2 个专栏收录

2 篇文章 0 订阅

订阅专栏

服务器

1 篇文章 0 订阅

订阅专栏

nginx是一款非常优秀轻型的http服务器，可以并大量达到5w，灰常旁观的数量，再加上它运行非常稳定，cpu内存占用的比较少，最主要的是他免费!!!,免费!!!免费!!! 重要的事情说三遍！！！

今天主要记录下Nginx的这几个方面：

《原理》关于反向代理和正向代理和负载均衡
《了解》常用Web服务器介绍
《了解》Nginx、Apache、Tomcat之间的区别以及联系
《了解》Nginx安装部署
《重要》Nginx核心配置分析
《熟练》虚拟主机的配置
《熟练》Location匹配规则剖析Rewrite的使用
《熟练》关于Nginx日志配置和及切割处理
《了解》缓存配置及Gzip配置
10.《重要》负载均衡配置说明
11.《原理》《重要》Nginx的进程模型
12.《了解》Nginx+keepalived

《原理》关于反向代理和负载均衡

说到代理，很多人都会有疑问，为什么会有代理，换句话说也就是代理的好处。
现在微信活的不要不要的，很多商人都会发展下线，邀请很多人加盟，这些人也就是所谓的代理(好处：人多力量大，赚钱更快)，既然这样，我们的服务器代理又会有什么好处呢？

提高访问效率

   你访问的目标服务器会存在代理服务器中，这样就能够起到浏览器的缓存作用，下次访问效率更高

突破访问限制

   就比如你要访问国外的谷歌或者一些其他翻墙的软件

更加安全

   可以给直接访问的用户隐藏自己的IP,也可以过滤一些不太友好的访问

a)正向代理：

既然聊到了反向代理，我们就先了解正向代理。(那生活中的例子说事)
一个女生A喜欢梵蒂冈口红，但是她并不知道那个厂C商购买，有一天啊，她发现了朋友圈中有一个做微商的B，然后他就直接去找B这个人。
(本来A是去找C的，但是找不到C,找到了B，B在这里就担任的是代理的角色)

b).反向代理：

拿我公司的情况说事吧(中国银联)
公司有三台服务器，然后比如说啊，我和同事需要访问中国银联的时候，有四台服务器，谁也不能确定访问的是那台服务器(上图说话)
在这里插入图片描述

main：用于进行nginx全局信息的配置
events：用于nginx工作模式的配置
http：用于进行http协议信息的一些配置
server：用于进行服务器访问信息的配置
location：用于进行访问路由的配置
upstream：用于进行负载均衡的配置

当你需要重启nginx的时候，可以先执行./nginx -t (检验你的语法是否错误的)

在这里插入图片描述
正向代理和反向代理的区别：
a).正向代理主要是针对客户端的,反向代理主要是针对服务器端的
b).反向代理能够实现高并发，以减少服务器的压力
c).正向代理是够对目标服务器隐藏信息，反向代理能够隐藏客户不知道访问的是那台服务器（这样说有点不太合适感觉）

c).负载均衡

负载均衡是建立在反向代理基础之上的，他最大的作用就是为了减轻服务器的访问压力。

常见的方法都有：

weight（权重）

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。如下所示，10.0.0.88的访问比率要比10.0.0.77的访问比率高一倍。

upstream linuxidc{
server 10.0.0.77 weight=5;
server 10.0.0.88 weight=10;
}

ip_hash（访问ip）

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

upstream favresin{
ip_hash;
server 10.0.0.10:8080;
server 10.0.0.11:8080;
}

fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。与weight分配策略类似。

upstream favresin{
server 10.0.0.10:8080;
server 10.0.0.11:8080;
fair;
}

url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

注意：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法。

upstream resinserver{
server 10.0.0.10:7777;
server 10.0.0.11:8888;
hash $request_uri;
hash_method crc32;
}

upstream还可以为每个设备设置状态值，这些状态值的含义分别如下：

down 表示单前的server暂时不参与负载.

weight 默认为1.weight越大，负载的权重就越大。

max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误.

fail_timeout : max_fails次失败后，暂停的时间。

backup：其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

upstream bakend{ #定义负载均衡设备的Ip及设备状态
ip_hash;
server 10.0.0.11:9090 down;
server 10.0.0.11:8080 weight=2;
server 10.0.0.11:6060;
server 10.0.0.11:7070 backup;
}

二.常见的Web服务器
对于我来说常见的有tomcat,nginx,Apache,Jetty等等其他的(weblogic,jboss,没有用过)
他们之间的区别以及联系又是什么呢？

大神链接：tomcat 与 nginx，apache的区别是什么？

我总结为如下： tomcat作为的是作为的是servlet容器，而nginx和Apache作为的是http server

比对下nginx和apache之间的区别以及联系：

Nginx

轻量级，采用 C 进行编写，同样的 web 服务，会占用更少的内存及资源
抗并发，nginx 以 epoll and kqueue 作为开发模型，处理请求是异步非阻塞的，负载能力比 apache 高很多，而 apache 则是阻塞型的。在高并发下 nginx 能保持低资源低消耗高性能，而 apache 在 PHP 处理慢或者前端压力很大的情况下，很容易出现进程数飙升，从而拒绝服务的现象。
nginx 处理静态文件好，静态处理性能比 apache 高三倍以上
nginx 的设计高度模块化，编写模块相对简单
nginx 配置简洁，正则配置让很多事情变得简单，而且改完配置能使用 -t 测试配置有没有问题，apache 配置复杂，重启的时候发现配置出错了，会很崩溃
nginx 作为负载均衡服务器，支持 7 层负载均衡
nginx 本身就是一个反向代理服务器，而且可以作为非常优秀的邮件代理服务器
启动特别容易, 并且几乎可以做到 7*24 不间断运行，即使运行数个月也不需要重新启动，还能够不间断服务的情况下进行软件版本的升级
社区活跃，各种高性能模块出品迅速

Apache

apache 的 rewrite 比 nginx 强大，在 rewrite 频繁的情况下，用 apache
apache 发展到现在，模块超多，基本想到的都可以找到
apache 更为成熟，少 bug ，nginx 的 bug 相对较多
apache 超稳定
apache 对 PHP 支持比较简单，nginx 需要配合其他后端用
apache 在处理动态请求有优势，nginx 在这方面是鸡肋，一般动态请求要 apache 去做，nginx 适合静态和反向。
apache 仍然是目前的主流，拥有丰富的特性，成熟的技术和开发社区

三.Nginx下载以及配置

https://blog.csdn.net/wt520it/article/details/85216714

Nginx虚拟配置：

注意：首先需要C:\Windows\System32\drivers\etc配置下host
在这里插入图片描述
虚拟主机配置最主要的两种方法：
a)基于域名(我们目前使用的方法)

b).基于端口

关于location和rewrite语法：

a)关于location

location ~* /js/.*/\.js
以 = 开头，表示精确匹配；如只匹配根目录结尾的请求，后面不能带任何字符串。
以^~ 开头，表示uri以某个常规字符串开头，不是正则匹配
以~ 开头，表示区分大小写的正则匹配;
以~* 开头，表示不区分大小写的正则匹配
以/ 开头，通用匹配, 如果没有其它匹配,任何请求都会匹配到

关于Location 后边加"/“和不加”/"的区别

首先是location进行的是模糊匹配
比如要访问的是localhost:8080/abc/def下边的目录
a).不加“/”的时候，还以访问defg，/defgh，/defghi 等等
b).加"/"的时候，只能访问的的是abc/def/anything路径

location匹配原则：

在这里插入图片描述

关于rewrite匹配规则：

rewrite功能就是使用nginx提供的全局变量或自己设置的变量，结合正则表达式和标志位实现url重写以及重定向。

《了解》关于Nginx日志配置和及切割处理

主要两种方式：

大家可以访问： nginx日志自动切割

《了解》缓存配置及Gzip配置

这两个配置都是为了提高访问效率的，GZip主要是针对一些比较大的图片进行压缩。

# 开启gzip
gzip on;
# 启用gzip压缩的最小文件，小于设置值的文件将不会压缩
gzip_min_length 1k;
# gzip 压缩级别，1-10，数字越大压缩的越好，也越占用CPU时间，后面会有详细说明
gzip_comp_level 2;
# 进行压缩的文件类型。javascript有多种形式。其中的值可以在 mime.types 文件中找到。
gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png font/ttf font/otf image/svg+xml;
# 是否在http header中添加Vary: Accept-Encoding，建议开启
gzip_vary on;
# 禁用IE 6 gzip
gzip_disable "MSIE [1-6]\.";

# 开启缓存
location ~* ^.+\.(ico|gif|jpg|jpeg|png)$ { 
    access_log   off; 
    expires      30d;
}

注意点：

图片、mp3这样的二进制文件，没必要做压缩处理，因为这类文件压缩比很小，压缩过程会耗费CPU资源
太小的文件没必要压缩，因为压缩以后会增加一些头信息，反而导致文件变大
Nginx默认只对text/html进行压缩，如果要对html之外的内容进行压缩传输，我们需要手动来配置

《重要》负载均衡配置说明

贴一段代码：至于什么作用我就不一一说明了

#######注意：每个结束的地方都必须有分号#######
#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           
        } 
    }
}

《原理》《重要》Nginx的进程模型

master进程：

充当整个进程组与用户的交互接口，同时对进程进行监护。它不需要处理网络事件，不负责业务的执行，只会通过管理work进程来实现重启服务、平滑升级、更换日志文件、配置文件实时生效等功能。主要是用来管理worker进程

接收来自外界的信号（前面提到的 kill -HUP 信号等）
我们要控制nginx，只需要通过kill向master进程发送信号就行了。比如kill -HUP pid，则是告诉nginx，从容地重启nginx，我们一般用这个信号来重启nginx，或重新加载配置，因为是从容地重启，因此服务是不中断的。master进程在接收到HUP信号后是怎么做的呢？首先master进程在接到信号后，会先重新加载配置文件，然后再启动新的worker进程，并向所有老的worker进程发送信号，告诉他们可以光荣退休了。新的worker在启动后，就开始接收新的请求，而老的worker在收到来自master的信号后，就不再接收新的请求，并且在当前进程中的所有未处理完的请求处理完成后，再退出
向各个worker进程发送信号
监控worker进程的运行状态
当worker进程退出后（异常情况下），会自动重新启动新的worker进程