nginx相关操作

1. nginx信号量与进程控制
   
   1. term int 迅速的关闭进程 相当于 ./sbin/nginx -s stop
   2. HUP 重新读取配置文件 开启新的工作进程 ./sbin/nginx -s reload
   3. USER1 用于日志分离时使用,重读配置文件 ./sbin/nginx -s reopen
   4. USER2 与 winch(关闭旧进程) 用于nginx升级时配置使用
2. nginx虚拟主机配置
   
   1. 1.

 `user  nobody;
worker_processes  1; //工作进程数: 一般配置为:cpu数*核数
// 如下 是日志相关记录配置
error_log  logs/error.log;
error_log  logs/error.log  notice;
error_log  logs/error.log  info;
pid        logs/nginx.pid;
events {
    // 一般是配置nginx连接的配置
    worker_connections  1024; // 此为 每个子进程的最大允许连接数
}
http {
    // 此为配置http服务器的配置
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" 
    access_log  logs/access.log  main;  // main是一种定义好的格式(该日志使用main格式)(远程Ip 等等)

    sendfile        on;
    tcp_nopush     on;

    keepalive_timeout  0;
    keepalive_timeout  65;

    gzip  on;

    server {
        listen       80; //监听端口
        server_name  localhost; //服务器域名

    #charset koi8-r;

    #access_log  logs/host.access.log  main;

    location / {
        root   html;  // 位置,此为相对路径(相对于nginx根目录)
        index  index.html index.htm; (缺省目录)
    }

    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   html;
    }

    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
    #    proxy_pass   http://127.0.0.1;
    #}

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
    #    root           html;
    #    fastcgi_pass   127.0.0.1:9000;
    #    fastcgi_index  index.php;
    #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
    #    include        fastcgi_params;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #    deny  all;
    #}   // location匹配顺序 : 精准匹配,如果成功,则返回,没匹配, 则进行普通匹配 --> 匹配多个->匹配长度优先 ->没匹配上 ->正则匹配 -> 匹配到则直接返回.

1. nginx rewrite
   1. 常用的命令
   1. if (条件) {} 设定条件,再进行重写
   2. set // 设置变量
   3. return //返回状态码
   4. break //调出rewrite
   5. rewrite //重写 //rewrite 正则 url (rewrite应该是这么用吧…)
   1. 对url进行重写.
   2. 判断语句
   2.1 if 空格( 条件 ) {

           }
           2.2  条件中使用的符号  "=" "~"(正则) ~*(不区分大小写的正则) -d-f-e (是否是文件夹,是否是文件,是否存在)
           2.3  rewrite的上下午环境是server或者location,所以 可以写在server内 或者 location内 然后进行业务操作
           2.4 
   

   -e表示只要filename存在，则为真，不管filename是什么类型，当然这里加了!就取反
   额外的一些

   -e filename 如果 filename存在，则为真
   -d filename 如果 filename为目录，则为真
   -f filename 如果 filename为常规文件，则为真
   -L filename 如果 filename为符号链接，则为真
   -r filename 如果 filename可读，则为真
   -w filename 如果 filename可写，则为真
   -x filename 如果 filename可执行，则为真
   -s filename 如果文件长度不为0，则为真
   -h filename 如果文件是软链接，则为真

对于Nginx的$request_filename变量指的就是请求的资源路径。在原先 OpenCDN节点端配置里面是这样的。
下边配置的含义是正则匹配 如果请求的以此结尾,则进入该location. if语句中的 -f表示判断该资源是否为文件.
// 如下的正则匹配中, "."表示匹配任意 , "\."将"."转义,表示匹配"."
location ~ .*\.(png|html|htm|ico|jpg|jpeg|bmp|gif|js|css)$ {
        ## 忽略浏览器的缓存
        proxy_ignore_headers Cache-Control;
        proxy_ignore_headers Expires;

        proxy_cache cache_one;
        proxy_cache_valid 200 304 1h;

        proxy_cache_key $host$uri$is_args$args;
        expires 1h;
        ## 此处为host锁定，可定制有无
        proxy_set_header        Host    $host;

        add_header OpenCDN-Cache "$upstream_cache_status";

       if (!-f $request_filename) {
                proxy_pass http://ocdn_www.firefoxbug.net;
                break;
        }
}

1. nginx gzip(压缩传输数据)

   1. 浏览器的请求头中, content-encoding:中 可以看到该浏览器支持的压缩方式

   2. gzip on|off 是否开启
      gzip_buffers 32 4k(一般是这个) | 16 8K 压缩在内存中缓冲几块,每块多大
      gzip_comp_level 推荐6
      gzip_disable 正则表达式,什么样的url不压缩
      gzip_min_length 开始压缩的最小长度 200
      gzip_http_version 开始压缩的http协议版本 1.0|1.1
      gzip_proxied 如果请求者是代理服务器,该如何缓存
      gzip_types text/plain application/xml 对那些类型进行压缩(默认就包括html)(mime.types配置文件中有各类型对应的格式)
      gzip_vary on|off 是否传输gzip压缩标志

      注: 二进制文件就不要压缩了..

2. expires 使用
   1. 图片(长期不易变得数据)等, 当用户在访问后,缓存在用户端.
   2. Context: server, location
   3. 可以使用 s m h d为单位等
   4. 可以在 location中 添加 图片等, 给其缓存加时长

3. location 定位

   1. 类型 location [=|~|~*|^~] patt{

   }

   1. location = patt {} [精准匹配]
   2. location patt{} [一般匹配]
   3. location ~ patt {} [正则匹配]
   4. 优先级 : 优先匹配 精准匹配
   5. 例子 如果: url=http://域名/,会先精准匹配,然后Url为 http:域名/index.html 在走下一个location,进行跳转 (不纠结这个地方…. )
      location = / {
      root html
      index index.html index.htm
      }
      location /index.html {
      root html
      index index.html index.htm
      }
   6. 正则表达式会覆盖掉其他

4. 反向代理 和 负载均衡

   1. 支持两个用法, proxy -> 反向代理 upstream ->负载均衡
   2. proxy
      在http节点下，添加upstream节点。

upstream linuxidc {
server 10.0.6.108:7080;
server 10.0.0.85:8980;
}

1. 将server节点下的location节点中的proxy_pass配置为：http:// + upstream名称，即“
   http://linuxidc”.

location / {
root html;
index index.html index.htm;
proxy_pass http://linuxidc;
}
此时,会出现一个问题. 那就是后端服务器会以为nginx的ip是客户端ip,所以需要在进行负载均衡的虚拟主机的location中 设置请求头中,携带用户的真正IP,既
proxy_set_header X-Forwarded-For $remote_addr;
3. 现在负载均衡初步完成了。upstream按照轮询（默认）方式进行负载，每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。虽然这种方式简便、成本低廉。但缺点是：可靠性低和负载分配不均衡。适用于图片服务器集群和纯静态页面服务器集群。

除此之外，upstream还有其它的分配策略，分别如下：

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;
}

Nginx的配置与部署研究，Upstream负载均衡模块 http://www.linuxidc.com/Linux/2013-04/82526p2.htm

CentOS 6.2实战部署Nginx+MySQL+PHP http://www.linuxidc.com/Linux/2013-09/90020.htm

使用Nginx搭建WEB服务器 http://www.linuxidc.com/Linux/2013-09/89768.htm

搭建基于Linux6.3+Nginx1.2+PHP5+MySQL5.5的Web服务器全过程 http://www.linuxidc.com/Linux/2013-09/89692.htm

CentOS 6.3下Nginx性能调优 http://www.linuxidc.com/Linux/2013-09/89656.htm

CentOS 6.3下配置Nginx加载ngx_pagespeed模块 http://www.linuxidc.com/Linux/2013-09/89657.htm

CentOS 6.4安装配置Nginx+Pcre+php-fpm http://www.linuxidc.com/Linux/2013-08/88984.htm

Nginx安装配置使用详细笔记 http://www.linuxidc.com/Linux/2014-07/104499.htm

Nginx日志过滤 使用ngx_log_if不记录特定日志 http://www.linuxidc.com/Linux/2014-07/104686.htm