статьи о Nginx

основное введение

Nginx — это легкий веб-сервер/обратный прокси-сервер/прокси-сервер электронной почты (IMAP/POP3), основными преимуществами которого являются:

Поддержка большого количества одновременных подключений, особенно статических интерфейсов, официальный тест Nginx может поддерживать 50 000 одновременных подключений.
Очень низкое использование памяти
Простая конфигурация, гибкое использование, возможность расширения своих функций в зависимости от собственных потребностей и поддержка разработки пользовательских модулей.

Гибкое использование: вы можете настроить различные режимы балансировки нагрузки, перезапись URL-адреса и другие функции по мере необходимости.
Высокая стабильность, низкая вероятность простоя при обратном прокси
Поддерживает горячее развертывание, приложение очень быстро запускается и перезагружается.

Основное использование

версия для Windows

Установить

Адрес загрузки файла:nginx.org/ru/docs/win…

Если загрузка идет медленно, вы можете использовать эту ссылку:

Ссылка на облачный диск Baidu:disk.baidu.com/yes/1st 3MSE G еще нет…Код извлечения: d8bi

Просто разархивируйте

основные команды

# 启动
# 建议使用第一种，第二种会使窗口一直处于执行中，不能进行其他命令操作
C:\server\nginx-1.19.2> start nginx
C:\server\nginx-1.19.2> nginx.exe

# 停止
# stop是快速停止nginx，可能并不保存相关信息；quit是完整有序的停止nginx，并保存相关信息
C:\server\nginx-1.19.2> nginx.exe -s stop
C:\server\nginx-1.19.2> nginx.exe -s quit

# 重载Nginx
# 当配置信息修改，需要重新载入这些配置时使用此命令
C:\server\nginx-1.19.2> nginx.exe -s reload

# 重新打开日志文件
C:\server\nginx-1.19.2> nginx.exe -s reopen

# 查看Nginx版本
C:\server\nginx-1.19.2> nginx -v

# 查看配置文件是否正确
C:\server\nginx-1.19.2> nginx -t

Простая демонстрация

использоватьSwitchHostПрограммное обеспечение редактирует отношение сопоставления между доменными именами и IP-адресами или каталогами.C:\Windows\System32\drivers\etcвниз, редактироватьhostsфайл, добавьте конфигурацию следующим образом (то же самое для Mac)
```
127.0.0.1  kerwin.demo.com
```
PS: Рекомендуемое программное обеспечениеSwitchHost, что практически необходимо при работе
Измените конфигурацию, как показано:

Эффект показан на рисунке:

Роль Nginx в архитектуре системы

Шлюз (главный вход для клиентов)
Виртуальный хост (предоставляют услуги для разных доменных имен/ip/портов. Например: виртуальный сервер VPS)
Маршрутизация (прямой прокси/обратный прокси)
статический сервер
Кластер нагрузки (обеспечивает балансировку нагрузки)

шлюз

Шлюз: его можно просто понимать как шлюз между запросами пользователей и ответами сервера, то есть общий вход для пользователей.

Шлюз может перехватывать все запросы клиента и выполнять контроль разрешений, балансировку нагрузки, управление журналами, мониторинг вызовов интерфейса и т. д. для запроса, поэтому независимо от того, какая архитектура системы используется, ее можно использовать.Nginxкак крайний шлюз

веб хостинг

Определение виртуального хоста: виртуальный хост — это специальная программно-аппаратная технология, которая может разделить каждый компьютер в сети на несколько виртуальных хостов, и каждый виртуальный хост может независимо предоставлять услуги www внешнему миру, так что один хост может предоставлять несколько внешних хостов. сервисы, каждый виртуальный хост независим и не влияет друг на друга.

Конфигурация виртуального хоста может быть достигнута через Nginx, Nginx поддерживает три типа конфигурации виртуального хоста.

Виртуальный хостинг на базе IP
Веб-хостинг на основе домена
виртуальный хостинг на базе портов

Форма выражения на самом деле, каждый больше, а именно:

# 每个 server 就是一个虚拟主机
http {
    # ...
    server{
        # ...
    }
    
    # ...
    server{
        # ...
    }
}

маршрутизация

существуетNginxВ конфигурационном файле часто можно увидеть такую конфигурацию:

location / {
	#....
}

locationЗдесь играет роль маршрутизация, например, мы определяем два разных маршрута в одном и том же виртуальном хосте следующим образом:

location / {
	proxy_pass https://www.baidu.com/;
}
		
location /api {
	proxy_pass https://apinew.juejin.im/user_api/v1/user/get?aid=2608&user_id=1275089220013336&not_self=1;
 }

Эффект следующий:

Из-за наличия маршрутизации, она будет решена для нас позже.跨域问题Это дает определенные идеи, и удобнее настраивать контент и API-интерфейсы одновременно.

PS: Функция маршрутизации очень мощная,支持正则匹配

Прямой и обратный прокси

Дополнительные пояснения здесьproxy_passзначение

существуетNginxСредняя конфигурацияproxy_passПри переадресации по доверенности, еслиproxy_passдобавить URL после/, указывающий абсолютный корневой путь;

если нет/, указывающий относительный путь

прямой прокси

Работа для клиентов;
Скрыть реального клиента, отправлять и получать запросы для клиента и делать настоящего клиента невидимым для сервера;
Все пользователи в локальной сети могут перенаправляться сервером, отвечающим за HTTP-запросы;
Это означает, что связь с сервером осуществляется прямым прокси-сервером;

обратный прокси

прокси-сервер;
Настоящий сервер скрыт, отправляет и получает запросы на сервер, делая реальный сервер невидимым для клиента;
Сервер балансировки нагрузки, который распределяет пользовательские запросы на простаивающие серверы;
Это означает, что пользователь взаимодействует напрямую с сервером балансировки нагрузки, то есть, когда пользователь разрешает доменное имя сервера, получается IP-адрес сервера балансировки нагрузки;

точки соприкосновения

Оба служат средним уровнем между сервером и клиентом.
может усилить безопасность внутренней сети и предотвратить веб-атаки
Может использоваться как механизм кэширования для повышения скорости доступа.

разница

Прямой прокси-сервер фактически является прокси-сервером для клиента, а обратный прокси-сервер является прокси-сервером для сервера.
В прямом прокси сервер не знает, кто настоящий клиент, в обратном прокси клиент не знает, кто настоящий сервер.
Эффект отличается. Передовой прокси в основном используется для решения проблемы ограничений доступа; в то время как обратный прокси должен обеспечить балансировку нагрузки, защиту безопасности и другие функции.

статический сервер

статический серверNginxЕго сильные стороны очень просты в использовании.В конфигурации по умолчанию он указывает на статический HTML-интерфейс, например:

location / {
	root   html;
	index  index.html index.htm;
}

Итак, передние студенты, если вы построили интерфейс, вы можете настроить его соответствующим образом и указать интерфейс на целевую папку.rootОтноситсяhtmlпапка

балансировки нагрузки

Функция балансировки нагрузки есть.NginxЕще один большой убийца, всего есть 5 способов, на которых нужно сосредоточиться.

голосование

Каждый запрос распределяется по разным внутренним серверам один за другим в хронологическом порядке. Если внутренний сервер не работает, он может быть автоматически устранен. Конфигурация следующая:

upstream tomcatserver {
	server 192.168.0.1;
	server 192.168.0.2;
}

Стратегия циклического перебора является стратегией балансировки нагрузки по умолчанию.

Укажите веса

То есть на основе опроса, концепция увеличения веса,weightОн пропорционален коэффициенту доступа и используется в случае неравномерной работы backend-сервера.Конфигурация выглядит следующим образом:

upstream tomcatserver {
	server 192.168.0.1 weight=1;
	server 192.168.0.2 weight=10;
}

IP Hash

Каждый запрос распределяется в соответствии с результатом хэширования IP-адреса доступа, чтобы каждый посетитель мог получить фиксированный доступ к внутреннему серверу, что может решить проблему сеанса.Конфигурация выглядит следующим образом:

upstream tomcatserver {
	ip_hash;
	server 192.168.0.14:88;
	server 192.168.0.15:80;
}

fair

Стратегия балансировки нагрузки, предоставляемая третьей стороной, распределяет запросы в соответствии со временем отклика внутреннего сервера. Приоритет отдается короткому времени отклика. В производственной среде существуют различные ситуации, которые могут привести к колебаниям времени отклика, поэтому нужно использовать с осторожностью

upstream tomcatserver {
	server server1;
	server server2;
	fair;
}

url_hash

Стратегия балансировки нагрузки, предоставленная третьей стороной, распределяет запросы в соответствии с результатом хеширования URL-адреса доступа, так что каждый URL-адрес направляется на один и тот же внутренний сервер.

upstream tomcatserver {
	server squid1:3128;
	server squid2:3128;
	hash $request_uri;
	hash_method crc32;
}

Модульный дизайн Nginx

Первый взглядNginxСхема архитектуры модуля:

Важность этих 5 модулей уменьшается сверху вниз.

(1) основные модули;

Модуль ядра — это незаменимый модуль для нормальной работы сервера Nginx, как и ядро операционной системы. Он предоставляет самые основные основные услуги Nginx. Например, управление процессами, контроль разрешений, регистрация ошибок и т. д .;

(2) стандартный HTTP-модуль;

Стандартный модуль HTTP поддерживает стандартные функции HTTP, такие как: конфигурация порта, настройки кодирования веб-страницы, настройки заголовка HTTP-ответа и т. д.;

(3) Дополнительный модуль HTTP;

Дополнительный модуль HTTP в основном используется для расширения стандартных функций HTTP, позволяя Nginx обрабатывать некоторые специальные сервисы, такие как: парсинг запросов GeoIP, поддержка SSL и т. д.;

(4) модуль почтовой службы;

Модуль почтовой службы в основном используется для поддержки почтовой службы Nginx;

(5) сторонние модули;

Сторонний модуль предназначен для расширения серверного приложения Nginx и выполнения функций, которые нужны разработчикам, таких как: поддержка Lua, поддержка JSON и т. д.;

Модульная конструкция упрощает разработку и расширение Nginx, а его функции очень эффективны.

Процесс обработки запросов Nginx

На основании вышеизложенногоNginxМодульная структура, можно легко подумать, что на этапе обработки запроса будет много процессов,Nginx Каждый функциональный модуль организован в цепочку, при поступлении запроса запрос проходит через некоторые или все модули этой цепочки для обработки, и каждый модуль реализует определенную функцию.

Обработка HTTP-запроса:

Инициализировать HTTP-запрос
Заголовки запроса обработки, тело запроса обработки
Если есть, вызовите обработчик, связанный с этим запросом (URL или местоположение)
Поочередно вызывать обработчик каждой фазы для обработки
Выходной контент в свою очередь обрабатывается модулем фильтра.

Многопроцессная модель Nginx

После запуска Nginx появитсяmaster процесс и несколькоworker процесс.

master Процесс в основном используется для управленияworker Процесс, включая получение сигналов из внешнего мира, отправку сигналов каждому рабочему процессу, отслеживание текущего состояния рабочего процесса и запуск рабочего процесса.

worker Процесс используется для обработки событий запроса от клиента. Несколько рабочих процессов равны, они одинаково конкурируют с клиентскими запросами, каждый процесс независим, и запрос может быть обработан только в процессе WORKER. Задается номер рабочего процесса, который обычно устанавливается в соответствии с количеством ядер ЦП машины, что связано с моделью обработки событий.

Модель процесса Nginx можно представить следующим рисунком:

Эта конструкция дает следующие преимущества:

1) Воспользуйтесь возможностями параллельной обработки многоядерных систем.

Современные операционные системы уже поддерживают многоядерные архитектуры ЦП, которые позволяют нескольким процессам работать на разных ядрах ЦП. Все рабочие процессы в Nginx полностью равнозначны. Это повышает производительность сети и уменьшает задержку запросов.

2) Балансировка нагрузки

Несколько рабочих рабочих процессов взаимодействует с межпроцессором для реализации балансировки нагрузки, что легче назначается более легким процессом работы, когда приходит запрос. Это также увеличивает производительность сети в определенную степень, уменьшая задержку запроса.

3) Процесс управления отвечает за мониторинг состояния рабочего процесса и управление его поведением.

Процесс управления не занимает много системных ресурсов, он просто используется для запуска, остановки, мониторинга или использования других действий для управления рабочими процессами. Во-первых, это повышает надежность системы: при сбое рабочего процесса управляющий процесс может запустить новый рабочий процесс, чтобы избежать снижения производительности системы. Во-вторых, процесс управления поддерживает такие операции, как обновление программы и изменение элементов конфигурации при работе службы Nginx, что упрощает достижение динамической масштабируемости и динамической настройки.

Как Nginx решает феномен шокирующего стада

Что такое шокирующее стадо?

Громовое стадо относится к тому, когда несколько процессов (многопотоков) блокируются и ждут одного и того же события в одно и то же время (состояние сна). Если происходит событие ожидания, оно пробуждает все ожидающие процессы (или потоки). В конце концов, только один процесс (поток) может получить «управление» этим временем и обработать событие, в то время как другие процессы (потоки) не могут получить «управление» и могут только повторно войти в состояние сна. производительность называется эффектом громоподобного стада.

Многопроцессная модель Nginx представлена выше, а типичная многопроцессная модель, как упоминалось в статье, несколько рабочих процессов равны, поэтому при поступлении запроса все процессы начнут конкурировать одновременно, и, наконец, выполняется только один, что неизбежно приведет к пустой трате ресурсов.

Идея Nginx для решения этой проблемы такова:Вместо того, чтобы позволять нескольким процессам одновременно прослушивать сокеты, принимающие соединения, пусть каждый процесс слушает по очереди., так что при наличии соединения прослушивается только один процесс, поэтому не должно быть проблем с шокирующей группой.

Конкретный метод: используя межпроцессную блокировку, каждый процесспытатьсяЧтобы получить эту блокировку, если получение прошло успешно, добавьте сокет прослушивания в набор ожидания и установите тайм-аут для ожидания установления соединения.Процесс, который не получит блокировку, удалит сокет прослушивания из набора ожидания.

Модель, управляемая событием и асинхронный неблокирующий IO

Продолжая вышеперечисленное, после того, как мы знаем многопроцессную модель Nginx, мы знаем, что на самом деле есть только несколько рабочих процессов, но почему мы все еще можем получить такие высокие характеристики параллелизма? Конечно, он использует модель, управляемую событиями и асинхронные Неблокирующие методы IO. Для обработки запроса.

Процесс ответа сервера Nginx на веб-запросы и их обработки основан на модели, управляемой событиями.Он включает в себя три основных блока, в том числе сборщики событий, отправители событий и обработчики событий.事件处理器, и вообще существует несколько способов обработчиков событий:

Каждый раз, когда отправитель события передает запрос, целевой объект создает новый процесс.
Каждый раз, когда отправитель события передает запрос, целевой объект создает новый поток для обработки.
Каждый раз, когда отправитель события передает запрос, целевой объект помещает его в список ожидающих событий и вызывает его, используя неблокирующий ввод-вывод.

Третий способ, при написании программного кода, логика сложнее двух предыдущих. Большинство веб-серверов пошли по третьему пути, постепенно формируя так называемые事件驱动处理库.

事件驱动处理库также известен как多路IO复用方法, наиболее распространенными являются следующие три: модель выбора, модель опроса и модель epoll.

Среди них Nginx использует по умолчаниюepollмодель, но также поддерживает другие модели событий.

epollПомощь заключается в том, что он предоставляет механизм, который позволяет процессу одновременно обрабатывать несколько одновременных запросов, не заботясь о конкретном статусе вызова ввода-вывода. IO-вызовы полностью управляются событийно-управляемой моделью. Таким образом, когда рабочий процесс получает запрос клиента, он вызывает IO для обработки. Если результат не может быть получен немедленно, он будет обрабатывать другие запросы, пока рабочий процесс в этот период ответа ждать не нужно, можно заняться другими делами, когда ИО вернется,epollРабочий процесс будет уведомлен; когда процесс будет уведомлен, он продолжит обработку невыполненных запросов.

Лучшие практики для настройки Nginx

В производственной среде или среде разработки Nginx обычно проксирует несколько виртуальных хостов.Если все файлы конфигурации записаны по умолчаниюnginx.conf, это будет выглядеть очень раздутым, поэтому каждый виртуальный файл рекомендуется помещать в отдельную папку, Nginx поддерживает такую конфигурацию, следующим образом:

http {
	# 省略中间配置

	# 引用该目录下以 .conf 文件结尾的配置
    include /etc/nginx/conf.d/*.conf;
}

Конкретная конфигурация файла выглядит следующим образом:

# Demo
upstream web_pro_testin {
	server 10.42.46.70:6003 max_fails=3 fail_timeout=20s;
	ip_hash;
}
 
server {
	listen 80;
	server_name web.pro.testin.cn;
	location / {
		proxy_pass http://web_pro_testin;
		proxy_redirect off;
		proxy_set_header Host $host;
		proxy_set_header X-Real-IP $remote_addr;
    }
 
    location ~ ^/(WEB-INF)/ {
		deny all;
    }
}

Полное описание параметров конфигурации Nginx

# 运行用户
user www-data;    

# 启动进程,通常设置成和cpu的数量相等
worker_processes  6;

# 全局错误日志定义类型，[debug | info | notice | warn | error | crit]
error_log  logs/error.log;
error_log  logs/error.log  notice;
error_log  logs/error.log  info;

# 进程pid文件
pid        /var/run/nginx.pid;

# 工作模式及连接数上限
events {
    # 仅用于linux2.6以上内核,可以大大提高nginx的性能
    use   epoll; 
    
    # 单个后台worker process进程的最大并发链接数
    worker_connections  1024;     
    
    # 客户端请求头部的缓冲区大小
    client_header_buffer_size 4k;
    
    # keepalive 超时时间
    keepalive_timeout 60;      
    
    # 告诉nginx收到一个新连接通知后接受尽可能多的连接
    # multi_accept on;            
}

#设定http服务器，利用它的反向代理功能提供负载均衡支持
http {
    # 文件扩展名与文件类型映射表义
    include       /etc/nginx/mime.types;
    
    # 默认文件类型
    default_type  application/octet-stream;
    
    # 默认编码
    charset utf-8;
    
    # 服务器名字的hash表大小
    server_names_hash_bucket_size 128;
    
    # 客户端请求头部的缓冲区大小
    client_header_buffer_size 32k;
    
    # 客户请求头缓冲大小
	large_client_header_buffers 4 64k;
	
	# 设定通过nginx上传文件的大小
    client_max_body_size 8m;
    
    # 开启目录列表访问，合适下载服务器，默认关闭。
    autoindex on;

    # sendfile 指令指定 nginx 是否调用 sendfile 函数（zero copy 方式）来输出文件，对于普通应用，
    # 必须设为 on,如果用来进行下载等应用磁盘IO重负载应用，可设置为 off，以平衡磁盘与网络I/O处理速度
    sendfile        on;
    
    # 此选项允许或禁止使用socke的TCP_CORK的选项，此选项仅在使用sendfile的时候使用
    #tcp_nopush     on;

    # 连接超时时间（单秒为秒）
    keepalive_timeout  65;
    
    
    # gzip模块设置
    gzip on;               #开启gzip压缩输出
    gzip_min_length 1k;    #最小压缩文件大小
    gzip_buffers 4 16k;    #压缩缓冲区
    gzip_http_version 1.0; #压缩版本（默认1.1，前端如果是squid2.5请使用1.0）
    gzip_comp_level 2;     #压缩等级
    gzip_types text/plain application/x-javascript text/css application/xml;
    gzip_vary on;

    # 开启限制IP连接数的时候需要使用
    #limit_zone crawler $binary_remote_addr 10m;
   
	# 指定虚拟主机的配置文件，方便管理
    include /etc/nginx/conf.d/*.conf;


    # 负载均衡配置
    upstream mysvr {
        # 请见上文中的五种配置
    }


   # 虚拟主机的配置
    server {
        
        # 监听端口
        listen 80;

        # 域名可以有多个，用空格隔开
        server_name www.jd.com jd.com;
        
        # 默认入口文件名称
        index index.html index.htm index.php;
        root /data/www/jd;

        # 图片缓存时间设置
        location ~ .*.(gif|jpg|jpeg|png|bmp|swf)${
            expires 10d;
        }
         
        #JS和CSS缓存时间设置
        location ~ .*.(js|css)?${
            expires 1h;
        }
         
        # 日志格式设定
        #$remote_addr与$http_x_forwarded_for用以记录客户端的ip地址；
        #$remote_user：用来记录客户端用户名称；
        #$time_local： 用来记录访问时间与时区；
        #$request： 用来记录请求的url与http协议；
        #$status： 用来记录请求状态；成功是200，
        #$body_bytes_sent ：记录发送给客户端文件主体内容大小；
        #$http_referer：用来记录从那个页面链接访问过来的；
        log_format access '$remote_addr - $remote_user [$time_local] "$request" '
        '$status $body_bytes_sent "$http_referer" '
        '"$http_user_agent" $http_x_forwarded_for';
         
        # 定义本虚拟主机的访问日志
        access_log  /usr/local/nginx/logs/host.access.log  main;
        access_log  /usr/local/nginx/logs/host.access.404.log  log404;
         
        # 对具体路由进行反向代理
        location /connect-controller {
 
            proxy_pass http://127.0.0.1:88;
            proxy_redirect off;
            proxy_set_header X-Real-IP $remote_addr;
             
            # 后端的Web服务器可以通过X-Forwarded-For获取用户真实IP
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;

            # 允许客户端请求的最大单文件字节数
            client_max_body_size 10m;

            # 缓冲区代理缓冲用户端请求的最大字节数，
            client_body_buffer_size 128k;

            # 表示使nginx阻止HTTP应答代码为400或者更高的应答。
            proxy_intercept_errors on;

            # nginx跟后端服务器连接超时时间(代理连接超时)
            proxy_connect_timeout 90;

            # 后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据
            proxy_send_timeout 90;

            # 连接成功后，后端服务器响应的超时时间
            proxy_read_timeout 90;

            # 设置代理服务器（nginx）保存用户头信息的缓冲区大小
            proxy_buffer_size 4k;

            # 设置用于读取应答的缓冲区数目和大小，默认情况也为分页大小，根据操作系统的不同可能是4k或者8k
            proxy_buffers 4 32k;

            # 高负荷下缓冲大小（proxy_buffers*2）
            proxy_busy_buffers_size 64k;

            # 设置在写入proxy_temp_path时数据的大小，预防一个工作进程在传递文件时阻塞太长
            # 设定缓存文件夹大小，大于这个值，将从upstream服务器传
            proxy_temp_file_write_size 64k;
        }
        
        # 动静分离反向代理配置（多路由指向不同的服务端或界面）
        location ~ .(jsp|jspx|do)?$ {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_pass http://127.0.0.1:8080;
        }
    }
}

Что еще может Nginx

Решение междоменных проблем CORS

Есть две идеи:

На основе мультимаршрутизации этой проблемы можно избежать, отправив два междоменных запроса на соответствующие серверы, а затем унифицированный доступ к входу.
Воспользуйтесь функцией Nginx для настройки Headed и прикрепите к нему соответствующий заголовок запроса

Совместимость с ПК или мобильным устройством

По разным устройствам пользователей возвращаются разные стили сайтов.Раньше часто использовалась чистая адаптивная верстка фронтенда, но она не так хороша, как раздельное написание по сложности и удобству использования, как наш общий Taobao, Jingdong.... .. Эти крупные веб-сайты не являются адаптивными, а создаются отдельно по запросу пользователя.user-agentчтобы определить, следует ли вернуться на сайт ПК или H5

регулирование запроса

Модуль ограничения скорости Nginx в соответствии со скоростью запроса использует алгоритм дырявого ведра, который может принудительно гарантировать, что скорость обработки запроса в реальном времени не превысит установленный порог, например:

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
    server {
        location /search/ {
            limit_req zone=one burst=5 nodelay;
        }
    }
}

другие трюки

Такие как: защита изображений, фильтрация запросов, общая переадресация домена, настройка HTTPS и т. д.

Справочные статьи:«Nginx от начала до практики, подробное объяснение из десяти тысяч слов! 》

Общая проблема

Q1: Для чего обычно используется Nginx?

См. выше роль Nginx в системе архитектуры и что еще можно сделать с помощью Nginx, чтобы ответить

Q2: Зачем использовать Nginx?

Понимание необходимости шлюзов и способности Nginx обеспечивать высокую доступность и балансировку нагрузки.

Q3: Почему Nginx такой быстрый?

Если сервер принимает процесс, в котором один процесс отвечает за один запрос, то количество процессов равно количеству параллелизма. Тогда, очевидно, будет много ожидающих процессов. Чего же ты ждешь? Больше всего следует ждать передачи по сети.

И асинхронный неблокирующий способ работы nginx использует это время ожидания. Когда необходимо подождать, эти процессы простаивают и находятся в режиме ожидания. Таким образом, несколько процессов могут решить большое количество проблем параллелизма.

Как это использует nginx Проще говоря: для тех же четырех процессов, если один процесс отвечает за один запрос, то после того, как одновременно придет четыре запроса, каждый процесс отвечает за один из них, пока сессия не будет закрыта. В течение этого периода, если поступает 5-й запрос. Ответить вовремя невозможно, так как четыре процесса еще не закончили свою работу, поэтому обычно существует процесс планирования: всякий раз, когда приходит новый запрос, открывается новый процесс для его обработки.

В случае с nginx это не так: каждый раз, когда приходит запрос, будет рабочий процесс для его обработки. Но не весь процесс, до какой степени? Обработка до места, где может произойти блокировка, например, пересылка запроса на вышестоящий (внутренний) сервер и ожидание возврата запроса. Тогда обрабатывающий воркер не будет так тупо ждать.После отправки запроса он зарегистрирует событие: «Если апстрим вернется, дайте мне знать, и я продолжу». Так он отдыхал. В этот момент, если придет другой запрос, он сможет снова обработать его таким же образом в ближайшее время. Как только вышестоящий сервер вернется, это событие будет запущено, рабочий процесс возьмет на себя управление, и запрос продолжит выполняться.

Из-за рабочего характера веб-сервера большая часть жизни каждого запроса приходится на передачу по сети, и на самом деле квант времени, затрачиваемый на серверную машину, невелик. В этом секрет решения проблемы высокого параллелизма всего за несколько процессов.

Резюме: комбинированный эффект модели событий, асинхронной неблокирующей модели с несколькими процессами плюс детальная оптимизация.

Q4: Что такое прямой прокси и обратный прокси

см. выше

Q5: Каковы алгоритмы балансировки нагрузки Nginx?

см. выше

Q6: Как Nginx решает проблему шокирующей группы?

см. выше

Q7: Почему Nginx не использует многопоточную модель?

Глубокое понимание преимуществ многопроцессной модели плюс асинхронный неблокирующий ввод-вывод и недостатков переключения контекста в многопоточной модели.

Q8: Есть ли недостатки у функции сжатия Nginx?

Очень интенсивно использует ЦП

Q9: Сколько моделей процессов у Nginx?

На самом деле есть два типа, многопроцессорные и однопроцессорные, но в реальной работе все они многопроцессорные.

Ссылаться на

【Front-end Dictionary】Как объяснить боссу использование обратного прокси
[code.nginx] Модель сервера Nginx, управляемая событиями.
Модульный дизайн Nginx
Документация Nginx на китайском языке

Наконец

Если вы найдете этот контент полезным:

Конечно, ставьте лайки и поддерживайте~
Ищите и подписывайтесь на официальный аккаунт »это Кервин", болтаем вместе~
Давайте посмотрим на последние несколько статей »Заполнение пробелов», эта серия будет продолжать выпускаться~
- «Нахождение и заполнение пробелов» для консолидации вашей системы знаний Redis (смеется)
- «Поиск и заполнение пробелов» для консолидации вашей системы знаний RocketMQ