Nginx分布式框架详解-基础01-17基础讲解

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

  1. 代理服务器如果配置在客户端即为正向代理，如果配置在服务端即为反向代理，和机器个数没有关系；
  2. 正向代理代替客户端去发送请求，反向代理代替服务端去接收请求
  3. 正式因为正向代理代替客户端去发送请求，正向代理服务器和客户端对外表现为一个客户端，所以正向代理隐藏了真实的客户端；
    反向代理服务器代替服务端接收请求，反向代理服务器和真实服务器对外表现为一个服务端，所以反向代理服务器隐藏了真实的服务端；
  • 综上，本质上代理服务器还是那个代理服务器，如果代替客户端干活就是正向代理，如果代替服务端干活就是反向代理。

为什么有正向代理？

  1. 正向代理服务器有客户端缺少的功能，比如可以上网、FQ等等。假如公司服务器的软件在内网部署访问不了internet,就可以配置一台正向代理服务器,通过正向代理服务器上网。
  2. 配置正向代理举例：
    假设现在有一台主机上不了网，可以通过nginx代理该主机上网，配置如下：
server {
  listen 80;
  server_name 123.57.142.92;
  
  location /proxy_baidu/ {
    proxy_pass http://baidu.com/; 
  }
}

在浏览器中输入http://123.57.142.92/proxy_baidu 即可访问到百度主页

为什么有反向代理以举例

  1. 为什么有反向代理
    在高并发场景下，一个tomcat服务器可能承受不了那么高的并发量和访问量,所以需要多个服务器分担这个工作,而nginx在高并发的场景下表现是尤为突出的,此时nginx就可以代理多个服务器去接收用户请求,最后交给其中一个服务器处理.
  2. 配置反向代理举例
    在一台服务器上通过docker部署两个flask应用,用nginx做反向代理(负载均衡),nginx配置如下
    docker部署flask应用参考
upstream flask-demo-cluster {
    server 172.17.82.xxx:9080;
    server 172.17.82.xxx:9008;
}

server {
    listen 80;
    server_name flask-test.mayanan.cn;

    location /hello {
        proxy_pass http://flask-demo-cluster;
    }
}

浏览器输入：http://flask-test.mayanan.cn/hello 访问测试吧。

nginx如何禁用ip地址直接访问，只允许域名访问

禁止ip访问，这样做是为了避免其他人把未备案的域名解析到自己的服务器IP，而导致服务器被断网，我们可以通过禁止使用ip访问的方法，防止此类事情的发生
配置有两种：
假设我们的域名是www.baidu.com
1、第一种：
这种方法是插入一个新的server段的配置，

http{
    # 插入下面这个server段
    server {
        listen 80 default;         # 此处与下面的域名的80端口对应
        server_name _;
        return 403;
      }
    server {
      listen 80;
      server_name www.baidu.com;
     }
}

第二种：

http{
      server {
            listen 80;
            server_name www.baidu.com;
            if ($host != 'www.baidu.com'){
               return 403;
            }
     }
}

设置成功后，就只能用域名访问网站，不能用ip访问了，如何使用ip访问则会报出403禁止访问的页面，如果你想自定义错误的页面，可以如下所示：

server {
    listen 80 default;
    server_name _;
    root /srv/www/;
    index 500.html;
}

nginx的优点

  1. 速度更快，并发更高
    nginx之所以有这么高的并发处理能力和这么好的性能原因在于：nginx采用了多进程和I/O多路复用（epoll）底层实现
  2. 配置简单、扩展性强
  3. 高可靠性
    每个worker进程之间都可相互独立的提供服务，并且master主进程可以在worker进程出错时，快速去拉取新的worker进程提供服务。
  4. 热部署
    即可在nginx不停止的情况下，对nginx进行文件升级，更新配置和更换日志文件等功能
  5. 成本低、BSD许可证

nginx常用的功能模块

  1. 静态资源部署
  2. Rewrite地址重写（正则表达式）
  3. 反向代理
  4. 负载均衡 （轮询、加权轮询、ip_hash、url_hash、fair）
  5. web缓存（提升服务器响应的速度）
  6. 环境部署（高可用的环境）
  7. 用户认证模块
    ...

nginx的核心组成

  1. nginx二进制可执行文件（可进行nginx的启动、关闭、加载）
  2. nginx.conf配置文件
  3. error.log错误日志记录
  4. access.log访问日志记录

nginx源码复杂安装

参考文档

nginx目录结构分析

在使用 Nginx 之前，我们先对安装好的 Nginx 目录文件进行一个分析，在这块给大家介绍一个工具 tree，通过 tree 我们可以很方面的去查看 Centos 系统上的文件目录结构，当然，如果想使用 tree 工具，就得先通过 yum install -y tree 来进行安装，安装成功后，可以通过执行 tree /usr/local/nginx (tree 后面跟的是 Nginx 的安装目录)，获取的结果如下：

CGI(Common Gateway Interface)通用网关【接口】，主要解决的问题是从客户端发送一个请求和数据，服务端获取到请求和数据后可以调用调用 CGI【程序】处理及相应结果给客户端的一种标准规范。

目录 文件名 作用
conf Nginx 所有配置文件目录
fastcgi.conf fastcgi相关配置文件
fastcgi.conf.default fastcgi.conf 的备份文件
fastcgi_params fastcgi 的参数文件
fastcgi_params.default fastcgi 的参数备份文件
scgi_params scgi 的参数文件
scgi_params.default scgi 的参数备份文件
uwsgi_params uwsgi 的参数文件
uwsgi_params.default uwsgi 的参数备份文件
mime.types 记录的是 HTTP 协议中的 Content-Type 的值和文件后缀名的对应关系
mime.types.default mime.types 的备份文件
nginx.conf 这是 Nginx 的核心配置文件，这个文件非常重要，也是我们即将要学习的重点
nginx.conf.default nginx.conf 的备份文件
koi-utf、koi-win、win-utf 这三个文件都是与编码转换映射相关的配置文件，用来将一种编码转换成另一种编码
html 存放 Nginx 自带的两个静态的 html 页面
50x.html 访问失败后的失败页面
index.html 成功访问的默认首页
logs 记录入门的文件，当 Nginx 服务器启动后，这里面会有 access.log error.log 和 nginx.pid 三个文件出现
access.log 访问日志，每次访问成功都会进行记录
error.log 错误日志，每次访问失败都会进行记录
nginx.pid 启动 Nginx 后，系统生成一个进程 PID，这个文件记录这个 PID
sbin 是存放执行程序文件 nginx
nginx 用来控制 Nginx 的启动和停止等相关的命令。注意：该文件名就叫 nginx

nginx服务启停命令

对于 Nginx 的启停在 Linux 系统中也有很多种方式，我们介绍两种方式：

  1. Nginx 服务的信号控制
  2. Nginx 的命令行控制

nginx服务的信号控制

问题
Nginx 中的 master 和 worker 进程?
Nginx 的工作方式?
如何获取进程的 PID?
信号有哪些?
如何通过信号控制 Nginx 的启停等相关操作?
前面在提到 Nginx 的高性能，其实也和它的架构模式有关。Nginx 默认采用的是多进程的方式来工作的，当将 Nginx 启动后，我们通过 ps -ef | grep nginx 命令可以查看到如下内容：

ps -ef|grep nginx

root     31391     1  0 14:42 ?        00:00:00 nginx: master process ./nginx
nobody   31392 31391  0 14:42 ?        00:00:00 nginx: worker process
root     31748 20530  0 16:35 pts/1    00:00:00 grep nginx

从上图中可以看到，Nginx 后台进程中包含一个 master 进程和多个 worker 进程，master 进程主要用来管理 worker 进程，包含接收外界的信息，并将接收到的信号发送给各个 worker 进程，监控 worker 进程的状态。当 worker 进程出现异常退出后，会自动重新启动新的 worker 进程。而 worker 进程则是专门用来处理用户请求的，各个 worker 进程之间是平等的并且相互独立，处理请求的机会也是一样的。

Nginx 的进程模型，我们可以通过下图来说明下：

nginx默认的是多进程的工作方法：一个master进程和多个worker进程。
我们现在作为管理员，只需要通过给 master 进程发送信号就可以来控制 Nginx，这个时候我们需要有两个前提条件，一个是要操作的 master 进程，一个是 给 master 进程的信号。

  1. 要想操作 Nginx 的 master 进程，就需要获取到 master 进程的进程号 PID。获取方式简单介绍两个：
    方法1：ps -ef | grep nginx
    方法2：在讲解 Nginx 的 ./configure 的配置参数的时候，有一个参数 --pid-path=PATH，它的默认值是 /usr/local/nginx/logs/nginx.pid，所以可以通过查看该文件来获取 Nginx 的 master 进程 PID
    cat /usr/local/nginx/logs/nginx.pid
  2. 信号
信号 作用
TERM/INT 立即关闭整个服务（关闭 Nginx）
QUIT 「优雅」的关闭整个服务（关闭 Nginx）
HUP 重读配置文件并使用服务对新配置项生效（重启 Nginx）
USR1 重新打开日志文件，可以用来进行日志切割（重启日志）
USR2 平滑升级到最新版的 Nginx
WINCH 所有子进程不在接收处理新连接，相当于给 Work 进程发送 QUIT 指令

调用命令为kill -signal PID
signal：即为信号；PID 即为获取到的 master 进程 PID

案例：

  1. 发送TERM/INT信号给master进程，会将nginx服务立即关闭
# 立即关闭当前进程
kill -TERM `cat /usr/local/nginx/logs/nginx.pid`
# 立即关闭当前进程
kill -INT `cat /usr/local/nginx/logs/nginx.pid`
  1. 发送QUIT信号给master进程，master进程会控制所有的worker进程不在接收新的请求，等待所有请求都处理完后，在把进程都关闭掉
# 优雅的关闭进程
kill -QUIT `cat /usr/local/nginx/logs/nginx.pid`
  1. 发送 HUP 信号给 master 进程，master 进程会把控制旧的 worker 进程不再接收新的请求，等处理完请求后将旧的 worker 进程关闭掉，然后根据更改Nginx 的配置文件重新启动新的 worker 进程
# 重启worker进程（同时重新加载更新后的配置文件）
kill -HUP `cat /usr/local/nginx/logs/nginx.pid`
  1. 发送 USR1 信号给 master 进程，告诉 Nginx 重新开启日志文件。如果日志文件被删除了，可以利用此命令重新打开。
# 重新打开当前nginx的日志文件
# 方法1
kill -USR1 `cat /usr/local/nginx/logs/nginx.pid`
# 方法2
/usr/local/nginx/sbin/nginx -s reopen
  1. 发送 USR2 信号给 master 进程，告诉 master 进程要平滑升级，这个时候，会重新开启对应的 master 进程和 worker 进程，整个系统中将会有两个master 进程，并且新的 master 进程的 PID 会被记录在 /usr/local/nginx/logs/nginx.pid，而之前的旧的 master 进程 PID 会被记录在 /usr/local/nginx/logs/nginx.pid.oldbin 文件中，接着再次发送 QUIT 信号给旧的 master 进程，让其处理完请求后再进行关闭
# 开启新的进程，但是不删除旧的进程
kill -USR2 `cat /usr/local/nginx/logs/nginx.pid`

当新进程升级后（完全启动后），再关闭旧的进程，旧进程的 PID 在另一个 nginx.pid.oldbin 文件里

# 关闭旧的进程
kill -QUIT `cat /usr/local/nginx/logs/nginx.pid.oldbin`
  1. 发送 WINCH 信号给 master 进程,让 master 进程控制不让所有的 worker 进程在接收新的请求了，请求处理完后关闭 worker 进程。注意 master 进程不会被关闭掉
# 处理完请求后停止当前worker进程，但是不会停止当前master进程
kill -WINCH `cat /usr/local/nginx/logs/nginx.pid`

4的案例：实现nginx日志的每日切割
shell脚本实现nginx日志每日自动切割

posted @ 2022-08-14 07:59  专职  阅读(122)  评论(0)  编辑  收藏  举报