The pre-fork model
Используется в Apache. Для каждого (на самом деле каждый форк обрабатывает несколько запросов, это количество определяется конфигом) запроса делается свой форк (копия процесса в unix). Каждый форк имеет.1 поток и обрабатывает лишь один запрос в каждый момент времени. pre означает, что форки создаются заранее. Получается как бы "пул форков".
- Модель полезна, когда используются не-потокобезопасные библиотеки.
- Проблемы, возникающие при обработке запроса повлияют только на этот форк, а не на весь сервер.
- Мастер-процесс определяет размер пула форков, может динамически его изменять.
Помимо этой модели, в Apache есть еще mpmworker (создаются несколько воркеров, каждый имеет несколько потоков) и mpmevent (похож на mpm_worker, но оптимизирован под работу с keep-alive соединениями, для которых выделяет отдельные потоки)
Throughput
Максимальная пропускная способность сети TP <= window / RTT
где:
TP = Throughput window = TCP window (buffer) size - размер одного пакета, на моем макбуке = 128 КБ RTT = round-trip time, он же пинг - время отправки запроса + время получения на него ответа.
HTTP Keep-Alive
При установке заголовка Keep-Alive соединения переиспользуются при следующих запросах. В этом случае нам не нужно заново делать рукопожатие и постепенное нарастание window size (flow control).
Конфликтует с моделью prefork, так как соединения не рвутся и даже небольшое количество пользователей исчерпывает пул форков полностью.
Apache VS Nginx
Nginx хорош для обработки статики и проксирования динамических запросов на другие сервера. Очень легковесный и быстрый. Легко масштабируется. Был создан для решения проблемы C10K. Решает ее благодаря асинхронной event-driven архитектуре.
Apache хорош для динамических запросов. Имеет много интеграций со сторонним софтом.
Nginx создает однопоточные воркеры, каждый из которых может обрабатывать тысячи соединений. Каждое событие помещается в event loop. В этом цикле события обрабатываются асинхронно.
Балансировка через DNS
Большинство клиентов использует первый IP-адрес в полученном списке, поэтому обычно сервера шлют список адресов каждый раз в разном порядке.
По RFC 1123 ответы от DNS должны сообщаться по UDP и иметь размер не более 512 байт. Размер 1 записи A-record - 16 байт. Размер заголовка пакета - 100 байт. Итого можем иметь не более, чем (512 - 100) / 16 = 25 серверов.
Главный недостаток такого подхода в том, что между нашим DNS-сервером и браузером обычно еще есть DNS на стороне провайдера, роутера, возможно локальный DNS на машине пользователя - и все со своими кэшами, возможно, с разным TTL.
Статические данные в этом случае нужно хранить на отдельных серверах, чтобы:
- не хранить несколько копий всех картинок (по одной на каждый сервер)
- запросы картинок не блокировали быстрые запросы к API
Перебор адресов на стороне клиента
Допустим, клиент получил от DNS несколько IP-адресов и выбрал один из них, к которому будет обращаться. После этого, при отказе этого сервера:
- если он лежит напрочь и никто по этому адресу не отвечает, то клиент будет честно ждать таймаут прежде чем обратиться к лседующему адресу
- если же сервер поднят, но на нем не запущен веб-сервис и никто не принимает соединение на порту 80, то клиент получает от него отказ за время, равное пингу, и клиент сразу же идет на следующий адрес
Балансировка через Nginx
Все просто - ставим сервер Nginx, настраиваем его как прокси с балансировкой.
Если нужно, можно несколько таких серверов поставить и настроить VRRP, то есть использование Virtual-IP, чтобы они работали под одним IP. При использовании VRRP один сервер маршрутизации становится мастер-роутером, а остальные - бэкап-роутерами. Если мастер становится недоступен, то его роль берет на себя один из бэкап-роутеров. Недостаток такого подхода - требуется сеть L2 между серверами.
Динамическая маршрутизация
Основные протоколы: BGP, OSPF.
Использование автономных систем
Автономная система - набор сетей под управлением одного администратора.
Подход заключается в том, что несколько точек в разных географических точках анонсируют один и тот же IP. Дальше маршрут от клиента до ДЦ автоматически выбирается провайдером на основании минимальной метрики.