nginx要点

最新推荐文章于 2023-03-23 17:14:19 发布

YJHKz

最新推荐文章于 2023-03-23 17:14:19 发布

阅读量202

点赞数 2

文章标签： nginx java

本文链接：https://blog.csdn.net/YJHKz/article/details/118303415

版权

nginx 要点

# nginx目录结构

.
├── client_body_temp
**├── conf** （etc）保存配置文件
│ ├── fastcgi.conf
│ ├── fastcgi.conf.default
│ ├── fastcgi_params
│ ├── fastcgi_params.default
│ ├── koi-utf
│ ├── koi-win
│ ├── mime.types
│ ├── mime.types.default
│ ├── **nginx.conf** 通常情况下使用的配置文件
│ ├── **nginx.conf.default 默认的** **通过这个文件恢复默认的配置**
│ ├── scgi_params
│ ├── scgi_params.default
│ ├── uwsgi_params
│ ├── uwsgi_params.default
│ └── win-utf
├── fastcgi_temp
├── **html**
│ ├── 50x.html
│ └── index.html
├── **logs** **保存的日志文件**
│ ├── **access.log 保存的是访问nginx 的记录**
│ ├── **error.log** **记录错误信息**
│ └── **nginx.pid** **保存进程id**
├── proxy_temp
│ ├── 1
│ │ └── 00
│ └── 2
│ └── 00
├── **sbin** **保存可执行文件**
│ └── nginx
├── scgi_temp
└── uwsgi_temp

# nginx 命令的使用

**题外：history |grep kafka**

-v : show version and exit

sbin/nginx -v ；查看版本

-V : show version and configure options then exit

sbin/nginx -V 查看版本和安装时候的配置选项

-t : test configuration and exit

sbin/nginx -t -c conf/nginx.conf.default 检查配置文件是否正确

-T : test configuration, dump it and exit

-q : suppress non-error messages during configuration testing

**-s signal : send signal to a master process: stop, quit, reopen, reload**

sbin/nginx -s stop ；停止nginx 服务。

sbin/nginx -s quit ；优雅的停止nginx服务。

sbin/nginx -s reopen ；重新记录日志。

sbin/nginx -s reload；重新加载配置文件，能够让配置文件平滑的过度生效。

-p prefix : set prefix path (default: /usr/local/nginx1.6/)

**-c filename : set configuration file (default: conf/nginx.conf)**

-g directives : set global directives out of configuration file

# 配置文件的结构

![1590376916987](C:\Users\45466\Desktop\1712D\教案\08-nginx要点\nginx 要点.assets\1590376916987.png)

    1. **全局块**：配置影响nginx全局的指令。一般有运行nginx服务器的用户组，nginx进程pid存放路径，日志存放路径，配置文件引入，允许生成worker process数等。
    2. **events块**：配置影响nginx服务器或与用户的网络连接。有每个进程的最大连接数，选取哪种事件驱动模型处理连接请求，是否允许同时接受多个网路连接，开启多个网络连接序列化等。
    3. **http块**：可以嵌套多个server，配置代理，缓存，日志定义等绝大多数功能和第三方模块的配置。如文件引入，mime-type定义，日志自定义，是否使用sendfile传输文件，连接超时时间，单连接请求数等、
    4. **server块**：配置虚拟主机的相关参数，一个http中可以有多个server。
    5. **location块**：配置请求的路由，以及各种页面的处理情况。

## 全局块

### 户配置

user elsearch; #使用这个用户启动工作进程

### 工作进程的配置

worker_processes 5; # 启动5个工作进程，通常这个数字就是cpu的核数。

### 进程id位置的配置

pid位置

### 错误日志的配置

## events

### 用户的将请求连接的个数。

worker_connections 1024;

## http块

### 支持媒体类型

include mime.types; #文件扩展名与文件类型映射表。

### 压缩配置

gzip on|off; #是否开启gzip

   gzip_buffers 32 4K| 16 8K #缓冲(压缩在内存中缓冲几块? 每块多大?)
   gzip_comp_level [1-9] #推荐6 压缩级别(级别越高,压的越小,越浪费CPU计算资源)
   gzip_disable #正则匹配UA 什么样的Uri不进行gzip
   gzip_min_length 200 # 开始压缩的最小长度(再小就不要压缩了,意义不在)
   gzip_http_version 1.0|1.1 # 开始压缩的http协议版本(可以不设置,目前几乎全是1.1协议)
   gzip_proxied # 设置请求者代理服务器,该如何缓存内容
   gzip_types text/plain application/xml # 对哪些类型的文件用压缩如txt,xml,html ,css
   gzip_vary on|off # 是否传输gzip压缩标志

### 错误日志

error_log file [level];
       第一个参数指定日志的写入位置。
       第二个参数指定日志的级别。level可以是debug, info, notice, warn, error, crit, alert,emerg中的任意值。
       可以看到其取值范围是按紧急程度从低到高排列的。只有日志的错误级别等于或高于level指定的值才会写入错误日志中。默认值是error。

### 访问日志

log_format main '$remote_addr ====$request_uri === - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

access_log logs/access2.log main;

| 变量名 | 定义 |
| ------------------------------------------------------------ | ------------------------------------------------------------ |
| $arg_PARAMETER | GET请求中变量名PARAMETER参数的值。 |
| $args | 这个变量等于GET请求中的参数。例如，foo=123&bar=blahblah;这个变量只可以被修改 |
| $binary_remote_addr | 二进制码形式的客户端地址。 |
| $body_bytes_sent | 传送页面的字节数 |
| $content_length | 请求头中的Content-length字段。 |
| $content_type | 请求头中的Content-Type字段。 |
| $cookie_COOKIE | cookie COOKIE的值。 |
| $document_root | 当前请求在root指令中指定的值。 |
| $document_uri | 与$uri相同。 |
| $host | 请求中的主机头(Host)字段，如果请求中的主机头不可用或者空，则为处理请求的server名称(处理请求的server的server_name指令的值)。值为小写，不包含端口。 |
| $hostname | 机器名使用 gethostname系统调用的值 |
| $http_HEADER | HTTP请求头中的内容，HEADER为HTTP请求中的内容转为小写，-变为_(破折号变为下划线)，例如：$http_user_agent(Uaer-Agent的值); |
| $sent_http_HEADER | HTTP响应头中的内容，HEADER为HTTP响应中的内容转为小写，-变为_(破折号变为下划线)，例如： $sent_http_cache_control, $sent_http_content_type…; |
| $is_args | 如果$args设置，值为"?"，否则为""。 |
| $limit_rate | 这个变量可以限制连接速率。 |
| $nginx_version | 当前运行的nginx版本号。 |
| $query_string | 与$args相同。 |
| $remote_addr | 客户端的IP地址。 |
| $remote_port | 客户端的端口。 |
| $remote_user | 已经经过Auth Basic Module验证的用户名。 |
| $request_filename | 当前连接请求的文件路径，由root或alias指令与URI请求生成。 |
| $request_body | 这个变量（0.7.58+）包含请求的主要信息。在使用proxy_pass或fastcgi_pass指令的location中比较有意义。 |
| $request_body_file | 客户端请求主体信息的临时文件名。 |
| $request_completion | 如果请求成功，设为"OK"；如果请求未完成或者不是一系列请求中最后一部分则设为空。 |
| $request_method | 这个变量是客户端请求的动作，通常为GET或POST。包括0.8.20及之前的版本中，这个变量总为main request中的动作，如果当前请求是一个子请求，并不使用这个当前请求的动作。 |
| $request_uri | 这个变量等于包含一些客户端请求参数的原始URI，它无法修改，请查看$uri更改或重写URI。 |
| $scheme | 所用的协议，比如http或者是https，比如rewrite ^(.+)$ $scheme://example.com$1 redirect; |
| $server_addr | 服务器地址，在完成一次系统调用后可以确定这个值，如果要绕开系统调用，则必须在listen中指定地址并且使用bind参数。 |
| $server_name | 服务器名称。 |
| $server_port | 请求到达服务器的端口号。 |
| $server_protocol | 请求使用的协议，通常是HTTP/1.0或HTTP/1.1。 |
| $uri | 请求中的当前URI(不带请求参数，参数位于args)，不同于浏览器传递的 |
| args)，不同于浏览器传递的request_uri的值，它可以通过内部重定向，或者使用index指令进行修改。不包括协议和主机名，例如/foo/bar.html | 请求中的当前URI(不带请求参数，参数位于args)，不同于浏览器传递的args)，不同于浏览器传递的request_uri的值，它可以通过内部重定向，或者使用index指令进行修改。不包括协议和主机名，例如/foo/bar.html |

## server

```properties
server {
listen 8888;
server_name www.zhuzhiguang1.com;
location / {
proxy_pass http://192.168.110.1:9002;
}
}

server {
listen 8888;
server_name www.zhuzhiguang2.com;
location / {
root /opt/myhtml;
#proxy_pass http://192.168.110.1:9003;
}
}

```

## location

### 代理的斜杠问题说明

假设下面四种情况分别用 http://192.168.1.105:9090/proxy/test 进行访问。

1. 第一种：后边都带斜杠
location /proxy/ {
proxy_pass http://192.168.1.105:9090/;
}
代理到URL：http://192.168.1.105:9090/test;

2. 第二种（相对于第一种，最后少一个 / ）
location /proxy/ {
proxy_pass http://192.168.1.105:9090;
}
代理到URL：http://192.168.1.105:9090/proxy/test

3. 第三种：
location /proxy/ {
proxy_pass http://192.168.1.105:9090/sub/;
}
代理到URL：http://192.168.1.105:9090/sub/test

4. 第四种（相对于第三种，最后少一个 / ）
location /proxy/ {
proxy_pass http://192.168.1.105:9090/sub;
}
代理到
URL：http://192.168.1.105:9090/subtest

![1590409808762](.\nginx 要点.assets\1590409808762.png)

**三****. 解析**

原请求路径：本文中统一为 "/foo/api"

location: 上面表格中的location列

proxy_pass：上面表格中的proxy_pass列

新请求路径：nginx将原请求路径处理过后的字符串

重点对 proxy_pass 进行分析，可以分为3种形式

然后按照ip:port后是否接了字符串归为2类，"/"也是字符串，因此1归为一类，2、3归为一类，下面对这两类情况进行说明

当 proxy_pass 的 ip:port 后未接字符串的时候，nginx 会将原请求路径原封不动地转交给下一站 nginx，如案例3和4

当 proxy_pass 的 ip:port 后接了字符串的时候，nginx 会将 location 从原请求路径中剔除，再将剩余的字符串拼接到 proxy_pass 后生成新请求路径，然后将新请求路径转交给下一站nginx（上面一种情况实际上和这个是一样的，只不过剔除的字符串是空串~~）

举个最让人疑惑的例子：案例7。proxy_pass 的 ip:port 后接了字符串 "/bar"，因此将 location："/foo/" 从原请求路径："/foo/api" 中剔除，变为"api"，再将"api"拼接到proxy_pass： http://192.168.1.48/bar 后生成了新请求url：" http://192.168.1.48/barapi "，因此下一站的nginx收到的请求就是 "/barapi"。

案例6：proxy_pass 的 ip:port 后接了字符串 "/bar/"，因此将 location："/foo" 从原请求路径 "/foo/api" 中剔除，变为 "/api"，再将 "/api" 拼接到proxy_pass： http://192.168.1.48/bar/ 后生成了新请求路径：" http://192.168.1.48/bar//api "，因此下一站的nginx收到的请求就是 /bar//api。

### location匹配的物种方式

   location 五个语法：
   匹配模式及顺序

　　1. = /uri

location = /uri 　　　=开头表示精确匹配，只有完全匹配上才能生效。
location = /nginx

2. ^~

　　location ^~ /uri 　　^~ 开头对URL路径进行前缀匹配，并且在正则之前。
location ^~ /static/

3. ~

location ~ pattern 　~开头表示区分大小写的正则匹配。
location ~ \.(gif|jpg|png|js|css)$

4. ~*

location ~* pattern 　~*开头表示不区分大小写的正则匹配。
location ~ \.(gif|jpg|png|js|css)$

5. /uri

location /uri 　　不带任何修饰符，也表示前缀匹配，但是在正则匹配之后。

6. 直接反斜杠 /

location / 　　通用匹配，任何未匹配到其它location的请求都会匹配到，相当于switch中的default。

### location 参数问题

   location ~* /wap/(\d+)/(.+)
   {
       proxy_pass http://mx$1.test.com:6601/$2?$args;
   }

## 负载均衡配置

负载均衡配置
nginx 负载均衡的配置

### 1、最基本的

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

location / {
proxy_pass http://linuxidc;
}

### 2、权重方式

默认10

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

### 3、ip_hash

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

### 4、url_hash（第三方）

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

### 5、fair（第三方）

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

### 6、关于其他选项

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 max_fails=1 fail_timeout=10s;
server 10.0.0.11:7070 backup;
}

down
表示当前的server临时不參与负载.
fail_timeout 与 max_fails：
Nginx基于连接探测，如果发现后端异常，在单位周期为fail_timeout设置的时间，
中达到max_fails次数，这个周期次数内，如果后端同一个节点不可用，那么接将把
节点标记为不可用，并等待下一个周期（同样时常为fail_timeout）再一次去请求，
判断是否连接是否成功。如果成功，将恢复之前的轮询方式，如果不可用将在下一
个周期(fail_timeout)再试一次。
默认：fail_timeout为10s,max_fails为1次。

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

### 技巧

#### 如何负载均衡到一个webapp下的多个项目

upstream mylinux{
server 127.0.0.1:8891;
server 127.0.0.1:8892;
server 127.0.0.1:8893;
}

server {
listen 8891;
server_name localhost;
location / {
proxy_pass http://localhost:8880/a/;
}
}

server {
listen 8892;
server_name localhost;
location / {
proxy_pass http://localhost:8880/b/;
}
}

server {
listen 8893;
server_name localhost;
location / {
proxy_pass http://localhost:8880/c/;
}
}

server {
listen 8085;
server_name localhost;
location / {
proxy_pass http://mylinux/;
}
}

# tomcat 自动部署

## tomcat 添加用户

vi conf/tomcat-users.xml

## 去掉ip的限制

编辑context.xml

allow="192\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />·

## pom.xml

org.apache.tomcat.maven
tomcat7-maven-plugin

8080
/
UTF-8
true
G://pic
/pic

http://192.168.110.134:8880/manager/text
boss
123456
true
/stu

## 运行的时候 tomcat7:deploy

YJHKz

关注

2
点赞
踩
2

收藏

觉得还不错? 一键收藏
1
评论
nginx要点

nginx 要点# nginx目录结构.├── client_body_temp**├── conf** （etc）保存配置文件│ ├── fastcgi.conf│ ├── fastcgi.conf.default│ ├── fastcgi_params│ ├── fastcgi_params.default│ ├── koi-utf│ ├── koi-win│ ├── mime.types│ ├── mime.types.defa...
复制链接

扫一扫