Nginx достаточно, чтобы прочитать эту статью!

Nginx

1. Модель процесса Nginx

Nginx — это модель процесса Master-Worker.
Основной процесс: Основной процесс, мониторинг рабочего процесса.
Рабочий процесс: Рабочий процесс, выполните соответствующую работу.
Количество рабочих процессов можно настроить в файле конфигурации.Конфигурация по умолчанию — 1, как показано на следующем рисунке.

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

2. Как работает рабочий процесс

2.1 Механизм вытеснения рабочего процесса

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

2.2 Асинхронные неблокирующие функции

Nginx является асинхронным неблокирующим
В Linux Nginx использует модель мультиплексирования ввода-вывода epoll, и каждый рабочий процесс может обрабатывать несколько клиентских запросов одновременно.
Файл conf по умолчанию

events {
   # 默认使用epoll
   use epoll;
   # 每个worker允许连接的最大数
   worker_connections  1024;
}

3. Детали конфигурации nginx.conf

3.1 Структура конфигурации nginx.conf

3.2 Конфигурация ядра nginx.conf

  1. Установка пользователя рабочего процесса, относящегося к пользователю в Linux, потребует некоторых разрешений для nginx для работы с каталогами или файлами.По умолчанию никто.


Если изменено на root, войдите в каталог sbin под nginx после изменения. ./nginx -s reloadКоманда перезапустилась, и было обнаружено, что следующий рабочий сменил пользователя с none на root.

2. Установите количество рабочих процессов.Вообще говоря, ядер процессора несколько, просто установите несколько или установите его на N-1.

3. уровень журнала nginx отладка | информация | уведомление | предупреждение | ошибка | крит | предупреждение | появление, уровень ошибки становится все больше и больше слева направо

4. Установите pid процесса nginx
Вышеупомянутые 3 и 4 указали определенные пути при установке nginx.nuggets.capable/post/690453…

  1. Установить рабочий режим
events {
# 默认使用epoll
use epoll;
# 每个worker允许连接的客户端最大连接数
worker_connections 10240;
}
  1. http — это командный блок, который используется для некоторых командных конфигураций передачи по сети http.
http {
}
  1. include вводит внешнюю конфигурацию, чтобы улучшить читаемость и избежать слишком большого размера одного файла конфигурации.
include mime.types;
  1. Установите формат журнала, main — это определенное имя формата, поэтому access_log может использовать эту переменную напрямую, также access.log указал определенный путь, когда мы установили nginx, здесь мы используем конфигурацию nginx по умолчанию.


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

  1. keepalive_timeout Установите время ожидания между клиентом и сервером, чтобы гарантировать, что соединение не будет устанавливаться повторно, когда клиент запрашивает несколько раз, экономя потребление ресурсов, единица измерения s.

  1. gzip позволяет сжимать html, css, js и другие файлы, что уменьшает размер и повышает эффективность передачи, но также снижает производительность сервера.

  2. серверный модуль - виртуальный хост, может быть настроен с несколькими

Пополнить:
Введите каталог SBIN и используйте команду ./nginx -tФайл конфигурации можно проверить на корректность.
Сводный график:

4. Ошибка открытия nginx.pid и неверные решения

1. Не удалось открыть 2. Неверный PID

5. Введение в общие команды Nginx

    nginx -s quit       优雅停止nginx,有连接时会等连接请求完成再杀死worker进程  

    nginx -s reload     优雅重启,并重新载入配置文件nginx.conf

    nginx -s reopen     重新打开日志文件,一般用于切割日志

    nginx -v            查看版本  
    
    nginx -V            详细版本信息,包括编译参数 

    nginx -t            检查nginx的配置文件

    nginx -h            查看帮助信息

    nginx  -c filename  指定配置文件

6. Нарезка логов Nginx

6.1 Ручная распиловка бревен

Существующие журналы существуют/var/log/nginx/каталог, который уже указал соответствующее место, когда мы его установили, включая два журнала/var/log/nginx/error.logа также /var/log/nginx/access.log, но с течением времени лог-файлов будет становиться все больше и больше, а объем будет становиться все больше и больше, что неудобно для просмотра эксплуатационному и обслуживающему персоналу, поэтому мы можем разрезать этот большой лог на несколько разных маленьких файлов как logs, Правило нарезки может быть основано на днях.Если есть сотни файлов G или несколько файлов T каждый день, то можно урезать на полдня или на час.
Конкретные шаги заключаются в следующем:
1. Создайте исполняемый файл оболочки: cut_my_log.sh со следующим содержимым: Обратите внимание, что следующие сценарии сокращены по минутам и могут быть изменены в соответствии с реальной сценой на работе и сокращены по дням:RECORD_TIME=$(date -d "yesterday" +%Y-%m-%d) .

#!/bin/bash
LOG_PATH="/var/log/nginx"
RECORD_TIME=$(date -d "yesterday" +%Y-%m-%d+%H:%M)
PID=/var/run/nginx/nginx.pid
mv ${LOG_PATH}/access.log ${LOG_PATH}/access.${RECORD_TIME}.log
mv ${LOG_PATH}/error.log ${LOG_PATH}/error.${RECORD_TIME}.log
# 向nginx主进程发送信号,用于重新打开日志
kill -USR1 `cat $PID`                         

2. Добавьте исполняемые разрешения для cut_my_log.sh.

chmod +x cut_my_log.sh

3. Результат разрезки журнала испытаний

./cut_my_log.sh

6.2 Раскрой бревна по времени

1. Установите временные задачи

yum install crontabs

2. crontab -e отредактировать и добавить новую строку задач

*/1 * * * * /usr/local/nginx/sbin/cut_my_log.sh

3. Перезапустите запланированное задание

service crond restart

Суммировать:

7. Используйте Nginx в качестве сервера статических ресурсов

7.1 HTML, CSS, JS и другая маршрутизация

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

imooc.conf настроен следующим образом:

Расположение здесь — это правило маршрутизации. Соответствующая конфигурация означает, что если мы обращаемся к каталогу /, он будет перенаправлен в каталог /home/foodie-shop/ под сервером.Домашняя страница — index.html, то есть, если мы получаем доступ к серверу ip: порт 90 будет направлен на index.html в рамках проекта foodie-shop.

7.2 Маршрутизация изображений, аудио и т. д.

Для других не-html, js, css и других ресурсов его также можно развернуть на nginx, здесь мы делаем следующую демонстрацию. Мы по-прежнему используем порт 90 в качестве маршрута и добавляем местоположение на тот же сервер, но учтите, что это больше не может быть /, потому что оно будет повторяться с местоположением / выше.Мы помещаем такие ресурсы, как изображения, аудио и видео в /home / Под папкой imooc при настройке локации делаем следующую настройку.

В настоящее время при доступе к /imoc автоматически соединяется /home и, наконец, получается правильный путь. Браузер может получить доступ к имени ресурса ip+90+/imooc/+.
Конечно, мы можем пойти дальше в виде псевдонимов. следующим образом:

Посетив /static здесь, вы найдете ресурсы из /home/imoc.

7.3 Введение в правила сопоставления местоположения

1. Пробел: соответствие по умолчанию, нормальное соответствие

location / {
	root /home;
}

2, = : точное совпадение

location = /imooc/img/face1.png {
     root /home;
}

3. ~* : соответствие регулярным выражениям без учета регистра.

# 符合图片的显示
location ~* \.(GIF|jpg|png|jpeg) {
 	root /home;
}

4. ~ : соответствие регулярным выражениям с учетом регистра.

# GIF必须大写才能匹配到,只要访问/home目录下的静态资源,就能路由到相应的文件,
# 比如home目录下有一个static文件夹,里面放着图片,那么访问ip+端口/static/1.jpg就可以访问到
location ~ \.(GIF|jpg|png|jpeg) {
 	root /home;
}

5. ^~ : начать с символьного пути

// 只能访问/imooc/img下的资源
location ^~ /imooc/img {
 	root /home;
}

8. Используйте сжатие Gzip для повышения эффективности запросов

   # 开启gzip压缩,目的:提高传输效率,节约带宽
    gzip  on;
   # 限制最小压缩,小于1字节文件不会压缩
    gzip_min_length 1;
   # 定义压缩的级别(压缩比,文件越大,压缩越多,但是cpu使用会越多)
    gzip_comp_level 3;
   # 定义压缩文件的类型
    gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png applicatio
n/json;

9. Междоменная конфигурация Nginx

Примечание. Как кросс-доменная конфигурация nginx, так и кросс-конфигурация springboot, упомянутая ранее, могут решить проблему междоменной интеграции, просто настройте ее.Наггетс.Талант/пост/688292…

Междоменная конфигурация:

    #允许跨域请求的域,*代表所有
    add_header 'Access-Control-Allow-Origin' *;
    #允许带上cookie请求
    add_header 'Access-Control-Allow-Credentials' 'true';
    #允许请求的方法,比如GET/POST/PUT/DELETE
    add_header 'Access-Control-Allow-Headers' *;
    #允许请求的header
    add_header 'Access-Control-Allow-Methods' *; 

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

#进程, 可更具cpu数量调整
worker_processes  1;
events {
    #连接数
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;

    #连接超时时间,服务器会在这个时间过后关闭连接。
    keepalive_timeout  10;

    # gizp压缩
    gzip  on;

    # 直接请求nginx也是会报跨域错误的这里设置允许跨域
    # 如果代理地址已经允许跨域则不需要这些, 否则报错(虽然这样nginx跨域就没意义了)
    
    #允许跨域请求的域,*代表所有
    add_header 'Access-Control-Allow-Origin' *;
    #允许带上cookie请求
    add_header 'Access-Control-Allow-Credentials' 'true';
    #允许请求的方法,比如GET/POST/PUT/DELETE
    add_header 'Access-Control-Allow-Headers' *;
    #允许请求的header
    add_header 'Access-Control-Allow-Methods' *; 
    
    # srever模块配置是http模块中的一个子模块,用来定义一个虚拟访问主机
    server {
        listen       80;
        server_name  localhost;
        
        # 根路径指到index.html
        location / {
            root   html;
            index  index.html index.htm;
        }

        # 重定向错误页面到/50x.html
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

    }

}

10. Конфигурация статического ресурса против пиявки в Nginx

Предотвратите кражу ссылок на изображения другими сайтами после междоменного доступа.
Добавьте следующую конфигурацию в nginx.conf.

#对源站点验证
valid_referers *.chen.com;
#非法引入会进入下方判断
if ($invalid_referer) { 
    return 404;
}

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

Пример выглядит следующим образом:

upstream tomcats {
   server 123.89.195.81:8080;
   server 123.89.195.82:8080;
   server 123.89.195.83:8080;
}

server {
        listen       80;
        server_name  123.89.195.79;
        location / {
            proxy_pass http://tomcats;
        }
}

На этом этапе доступ к номеру порта ip+80, на котором находится nginx, будет направлен на следующие три сервера tomcat.

12. Стратегия балансировки нагрузки Nginx

  • опрос (по умолчанию)

В соответствии с порядком в конфигурационном файле Nginx веб-запросы клиента по очереди распределяются по разным внутренним серверам.

#默认配置就是轮询策略
upstream server_group {
   server backend1.example.com;
   server backend2.example.com;
}
  • Веса
upstream server_group {
    server backend1.example.com weight=5;
    #默认为不配置权重为1
    server backend2.example.com;
}
  • ip_hash
hash(ip)%node_counts = index

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

upstream tomcats {
    ip_hash;
    server 192.168.1.173:8080;
    server 192.168.1.174:8080 down;
    server 192.168.1.175:8080;
}
  • url_hash

В соответствии с URL-адресом каждого запроса доступ к фиксированному серверному узлу осуществляется после хеширования.

upstream tomcats {
    # url hash
    hash $request_uri;
    server 192.168.1.173:8080;
    server 192.168.1.174:8080;
    server 192.168.1.175:8080;
}
server {
    listen 80;
    server_name www.tomcats.com;
    location / {
    proxy_pass http://tomcats;
}
  • least_conn

Запрос с наименьшим количеством подключений, запрос будет выделен серверу с наименьшим количеством подключений.

upstream tomcats {
    # 最少连接数
    least_conn
    server 192.168.1.173:8080;
    server 192.168.1.174:8080;
    server 192.168.1.175:8080;
}
server {
    listen 80;
    server_name www.tomcats.com;
    location / {
    proxy_pass http://tomcats;
}

13. Запись параметров восходящей команды

  • max_conns Максимальное количество подключений к узлу
upstream tomcats {
    server 192.168.1.173:8080 max_conns=2;
}
  • slow_start Медленное время запуска. Заставьте сервер присоединяться к кластеру медленно. Этот параметр нельзя использовать в хешировании и случайной балансировке нагрузки. Если в восходящем направлении только один сервер, этот параметр будет недействительным.
upstream tomcats {
    server 192.168.1.173:8080 weight=6 slow_start=60s;
    server 192.168.1.174:8080 weight=2;
    server 192.168.1.175:8080 weight=2;
}
  • Внутренний узел в автономном режиме, указывающий, что текущий сервер временно не участвует в нагрузке, серверный узел недоступен
upstream tomcats {
    server 192.168.1.173:8080 down;
    server 192.168.1.174:8080 weight=1;
    server 192.168.1.175:8080 weight=1;
}
  • Бэкап запасных нод, приданые только другие сервера, он выйдет в онлайн, добавьте его в кластер, параметр Backup нельзя использовать в Hash and Random Load Balancing.
upstream tomcats {
    server 192.168.1.173:8080 backup;
    server 192.168.1.174:8080 weight=1;
    server 192.168.1.175:8080 weight=1;
}
  • max_fails максимально допустимое количество сбоев
  • fail_timeout время ожидания после превышения максимального количества сбоев
max_fails=2 fail_timeout=15s

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

14. Улучшите производительность с помощью конфигурации поддержки активности

keepalive : установить количество длительных обработок соединения
proxy_http_version : установить версию HTTP для длинного соединения на 1.1.
proxy_set_header : очистить информацию о заголовке соединения

具体案例:
upstream tomcats {
    server 192.168.1.190:8080;
    keepalive 32;
}
  server {
      listen 80;
      server_name www.tomcats.com;
      location / {
      proxy_pass http://tomcats;
      proxy_http_version 1.1;
      proxy_set_header Connection "";
  }

15. Кейсы

Здесь записано, что на сервере Alibaba Cloud развернут nginx, на этом сервере развернуты статические ресурсы и фоновый код, а на tomcat развернут фоновый код.

upstream tomcats {
        server 121.**.195.81:8088;

}
server {
          listen       81;
          server_name  yun.j*-**-***.cn;
          location / {
              proxy_pass http://tomcats;
          }
        }            
server {
            listen       81;
            server_name  shop.j*-**-***.cn;、
            location / {
                root /home/website/foodie-shop;
                index index.html;
            }
        }
server {
            listen       81;
            server_name  center.j*-**-***.cn;
            location / {
                root /home/website/foodie-center;
                index index.html;
            }
        }

Один сервер соответствует трем разным доменным именам третьего уровня.Порт здесь установлен на 81, потому что доменное имя не было зарегистрировано, и по умолчанию он не может получить доступ к порту 80. В это время, когда мы обращаемся к разным доменным именам, мы будут поражать разные службы, nginx. Здесь обратный прокси-сервер реализован для службы интерфейса, развернутой фоновым котом, и реализовано динамическое и статическое разделение.