nginx的详解与应用

devops_sre

已于 2023-06-21 22:47:28 修改

阅读量1.1k

点赞数

文章标签： nginx 运维服务器

于 2023-06-10 18:51:37 首次发布

本文链接：https://blog.csdn.net/weixin_42715225/article/details/131140652

版权

前言

介绍

NGINX 是一种高性能、可扩展、安全且可靠的 Web 服务器和反向代理。NGINX 支持所有主要的 Web 加速技术来管理 HTTP 连接和流量。多年来，NGINX 的负载平衡、SSL 终止、连接和请求监管、静态内容卸载和内容缓存等功能帮助 NGINX 用户快速高效地构建可靠、快速的网站。

NGINX 还可以充当安全的应用程序网关，提供许多专门的内置接口来将流量从用户传递到应用程序。在这方面，NGINX 不仅可以将 HTTP 和 HTTPS 流量代理到支持 HTTP 的应用程序容器，它还可以通过FastCGI、Memcached等模块中实现的优化应用程序网关接口直接与大多数流行的轻量级应用程序服务器和 Web 框架对话, scgi和uwsgi。

大多数常用的应用程序容器都嵌入了具有某些路由功能的外部 HTTP 接口，但使用 NGINX 作为应用程序网关的一个重要原因是它为 HTTP 连接管理、负载平衡、内容缓存和流量提供了一体化解决方案安全。应用程序后端安全地位于 NGINX 后面，以获得更好的可扩展性和性能。将应用程序实例集群到 NGINX 后面以构建高可用性应用程序也非常容易

说明

负载均衡

平衡服务器、客户端和代理之间的网络流量是让客户满意和优化基础架构的关键

跨多个应用程序实例的负载平衡作用

优化资源利用率
最大化吞吐量
减少延迟
确保容错配置

方法：

Round Robin（默认）——按顺序在上游服务器上分发请求
Least Connections ——将请求转发到活动连接数最少的服务器
Hash – 根据指定的键分发请求，例如客户端 IP 地址或请求 URL。如果上游服务器集发生变化，可以选择应用一致的哈希来最小化负载的重新分配
IP Hash（仅限 HTTP）——根据客户端 IP 地址的前三个八位字节分配请求

被动健康检查

对于被动健康检查，NGINX 和 NGINX Plus 会在事务发生时对其进行监控，并尝试恢复失败的连接。如果事务仍然无法恢复，NGINX Open Source 和 NGINX Plus 会将服务器标记为不可用并暂时停止向其发送请求，直到它再次被标记为活动状态

上游服务器被标记为不可用的条件是为每个上游服务器定义的，并带有块server中指令的参数upstream：

fail_timeout – 设置服务器被标记为不可用的失败尝试次数必须发生的时间，以及服务器被标记为不可用的时间（默认为 10 秒）。
max_failsfail_timeout– 设置在服务器被标记为不可用期间必须发生的失败尝试次数（默认为 1 次尝试）

在下面的示例中，如果 NGINX 未能向服务器发送请求或在 30 秒内 3 次未收到服务器的响应，它将服务器标记为不可用 30 秒

upstream backend {
    server backend1.example.com;
    server backend2.example.com max_fails=3 fail_timeout=30s;
}

请注意，如果组中只有一台服务器，则忽略fail_timeout和max_fails参数并且服务器永远不会标记为不可用

要义

nginx 有一个master 进程和多个worker 进程。主进程的主要目的是读取和评估配置，以及维护工作进程。工作进程对请求进行实际处理。nginx 采用基于事件的模型和依赖于操作系统的机制在工作进程之间有效地分发请求。工作进程的数量在配置文件中定义，并且可以针对给定的配置固定或自动调整为可用 CPU 内核的数量worker_processes

句法：	worker_processes number | auto;
默认：	worker_processes 1;
语境：	main

定义工作进程的数量。最佳值取决于许多因素，包括（但不限于）CPU 核心数、存储数据的硬盘驱动器数和负载模式。当有疑问时，将其设置为可用CPU内核的数量将是一个好的开始（值“ auto”将尝试自动检测它）。auto从1.3.8和1.2.5版本开始支持该参数。

启动、停止和重新加载配置

要启动 nginx，请运行可执行文件。nginx 启动后，可以通过调用带有-s参数的可执行文件来控制它。使用以下语法：

nginx -s signal

其中signal可能是以下之一：

stop ==> 快速关机
quit ==> 优雅关机
reload ==> 重新加载配置文件
reopen ==> 重新打开日志文件

例如，要停止 nginx 进程并等待工作进程完成对当前请求的服务，可以执行以下命令：

nginx -s quit

在重新加载配置的命令发送到 nginx 或重新启动之前，不会应用在配置文件中所做的更改。要重新加载配置，请执行：

nginx -s reload

一旦主进程收到重新加载配置的信号，它就会检查新配置文件的语法有效性并尝试应用其中提供的配置。如果成功，主进程启动新的工作进程并向旧的工作进程发送消息，请求它们关闭。否则，主进程回滚更改并继续使用旧配置。旧工作进程收到关闭命令，停止接受新连接并继续为当前请求提供服务，直到所有此类请求都得到服务。之后，旧的工作进程退出。

借助kill实用程序等 Unix 工具，也可以将信号发送到 nginx 进程。在这种情况下，信号将直接发送到具有给定进程 ID 的进程。nginx master进程的进程ID，nginx.pid默认写入到目录下的/usr/local/nginx/logs或/var/run。例如master进程ID为1628，发送QUIT信号使nginx正常关闭，执行：

kill -9 QUIT 1628

要获取所有正在运行的 nginx 进程的列表，ps 可以使用该实用程序，例如，以下列方式：

ps -ax | grep nginx

有关向 nginx 发送信号的更多信息，请参阅控制 nginx

配置文件的结构

nginx由模块组成，这些模块由配置文件中指定的指令控制。指令分为简单指令和块指令。简单指令由名称和参数组成，以空格分隔并以分号结尾。块指令与简单指令具有相同的结构，但它以一组由大括号包围的附加指令结束，而不是分号。如果块指令可以在大括号内包含其他指令，则称为上下文（示例： events、 http、 server和 location）
放置在任何上下文之外的配置文件中的指令被认为是在main上下文中
#符号后一行的其余部分，被视为注释