Nginx Learning Series (2) ------------- Балансировка нагрузки

задняя часть сервер Nginx балансировки нагрузки
Nginx Learning Series (2) ------------- Балансировка нагрузки

Говоря о балансировке нагрузки, я бы сказал, что это несправедливо по своей сути. Почему ты это сказал? Представьте себе такой сценарий, кусок пирога разрезается на 5 частей, и теперь он делится между 3 людьми A, B и C. Исходя из принципа справедливости, мы говорим, что каждого человека можно нормально разделить на 5/ 3 части, а 5/3 части Очевидно, делить не просто, так случилось, что А не ел в полдень в это время, поэтому он мог съесть еще несколько порций, В и С были сыты, а 1 порция была достаточно.Исходя из принципа несправедливости, мы дали А 3 пирожных и пирожных В и С. Одна доля, которая делит ресурсы по определенной стратегии, является сбалансированной стратегией.

В веб-приложениях веб-приложение (или служба) обычно развертывается в кластере в производственной среде, а затем используется аппаратное (F5) или программное обеспечение (nginx) балансировки нагрузки для распределения запросов на различные узлы службы для обработки. пирог здесь эквивалентен нашему веб-запросу.Предположим, что поступает 5 запросов.Основываясь на определенной стратегии балансировки, мы можем передать 3 запроса на сервер A для обработки, а серверы B и C обрабатывают по 1 запросу. Ниже я рисую картинку, чтобы кратко проиллюстрировать эту модель:

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

1. Введение в балансировку нагрузки Nginx и связанные стратегии

Технология балансировки нагрузки незаменима для соответствующих стратегий балансировки. Nginx предоставляет стратегии балансировки 4. Мы можем выбрать подходящую стратегию балансировки в соответствии с конкретными бизнес-сценариями. Четыре стратегии равновесия описаны ниже:

  • 1. Стратегия балансировки на основе циклического перебора:

    Поллинг означает, что запросы, поступающие в nginx, распределяются по методу обхода: если запрос 1 распределяется на Сервер А, то запрос 2 будет распределяться на Сервер Б, ... и так далее.

  • 2. Стратегия балансировки на основе наименьшего количества подключений:

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

  • 3. Стратегия баланса на основе ip-хэша:

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

  • 4. Стратегия балансировки на основе взвешенного циклического перебора:

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

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

2. Введение в настройку различных стратегий балансировки Nginx

  • 1. Стратегия балансировки на основе циклического перебора:

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

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
    server {
        listen 80;

        location / {
            proxy_pass http://myapp1;
        }
    }
}

Видно, что для балансировки нагрузки nginx используется не так много инструкций, и две наиболее важные из них:upstreamиproxy_pass,upstreamБлок определяет внутренний небольшой кластер, и связанные серверы настроены для формирования этого кластера, и в то же времяupstreamДайте кластеру соответствующее имя, этот экземпляр называетсяmyapp1.proxy_passвlocationблок, указывающий, что для всех соответствующих/Запрос будет передан в какой кластер для обработки.Этот примерhttp://myapp1.

Но еще один момент, на который мы должны обратить внимание, вышеhttp://myapp1серединаmyapp1должно бытьupstreamИмя, от которого используется протоколhttpвсе ещеhttps, не имеет значения, использует ли ваш протоколhttps, тоhttpнепосредственно изменить наhttpsВот и все. Кроме того, если выupstreamсерединаserverИмя протокола задается в команде, затем вproxy_passНет необходимости добавлять имя протокола в команду.

Балансировка нагрузки Nginx реализована с использованием обратного прокси, что мы и использовали выше.proxy_passинструкции, поддерживаемые протоколы не толькоhttpиhttps, а также поддерживаетFastCGI,uwsgi,SCGI,memcached,gRPC, если вам нужно использовать в дополнение кhttp,httpsдругие протоколы мы не можем использоватьproxy_passвместо этого следует использовать соответствующую команду, напримерfastcgi_pass,uwsgi_pass,scgi_pass,memcached_pass,grpc_pass.

Эта стратегия справляется с нагрузкой, и я думаю, что она все еще имеет недостатки, и она не может предотвратить перегрузку сервера. Потому что если время выполнения некоторых запросов слишком велико, но параллелизм системы очень большой, это может привести к накоплению запросов на определенном сервере, и нагрузка будет слишком высокой.snowslide is possible~

  • 2. Стратегия балансировки на основе наименьшего количества подключений:

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

 upstream myapp1 {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

Эта стратегия более удобна для пользователя и может быть назначена в соответствии с фактическим состоянием машины.

  • 3. Стратегия баланса на основе ip-хэша:

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

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

Поскольку запросы от одного и того же клиента могут обрабатываться одним и тем же сервером, сеанс сеанса одного и того же клиента может быть постоянным.

  • 4. Стратегия балансировки на основе взвешенного циклического перебора:

Стратегия, основанная на взвешенном опросе, не нуждается в особом объяснении, то есть добавление информации о весе на основе опроса

upstream myapp1 {
    server srv1.example.com weight=3;
    server srv2.example.com;
    server srv3.example.com;
}

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

3. Дополнительные возможности и настройки балансировки нагрузки nginx.

  • 1. Проверка здоровья

    Медицинские осмотры нужны не только людям, но и машинам, поэтому пусть nginx будет доктором медицинского осмотра! Что такое проверка работоспособности nginx? Когда запрос поступает и распределяется на соответствующий сервер для обработки, nginx проверит, истекло ли время выполнения запроса, нет ли сбоя выполнения и т. д., а затем произведет соответствующую обработку --- например, когда nginx проверит, что Сервер A выполняет определенную ошибку 502, когда сообщается о запросе, тогда в следующий раз, когда nginx балансирует нагрузку, он будетupstreamСервер А исключается из блока, и запросы на Сервер А не распределяются.

    Для функции проверки работоспособности nginx предоставляет две основные инструкции, а именно:max_failsиfail_timeout, то есть когда nginx обнаруживает, что количество запросов с ошибкой на сервере достигаетmax_failsИли время выполнения выполнения запроса превышаетfail_timeoutТеперь при тайм-ауте nginx начнет использовать запросы в реальном времени для корректного определения сервера, при наличии ответа будет считать, что соответствующий сервер все еще жив и ничего страшного.

  • 2. Больше настроек

    для вышеперечисленногоupstreamв блокеserverкоманда, ее формат:server address [parameters];, внутриparametersТипов параметров может быть много, например указание серверу не участвовать в балансировке нагрузки и т. д. Для конкретной конфигурации, пожалуйста, обратитесь к ссылке на официальный сайт, нажмите здесьпортал.

Категории