Автор оригинала: Адам Чарнок
Исходная ссылка: Руководство для путешествующих автостопом по балансировке нагрузки PHP.
Перевод: Koda
раньше подразумевала запуск большого веб-сервера при запуске большого веб-приложения. Поскольку ваше приложение привлекает большое количество пользователей, вам придется добавить на сервер больше памяти и процессоров.
Сегодня модель «большого сервера» ушла в прошлое, ее заменило большое количество небольших серверов, использующих различные методы балансировки нагрузки. Это более осуществимый подход, который позволит свести затраты на оборудование к минимуму.
Преимущество «большего количества маленьких серверов» по сравнению с прежней моделью «большого сервера» отражено в двух аспектах:
если сервер выйдет из строя, система балансировки нагрузки перестанет отправлять запросы к вышедшему из строя серверу и вместо этого распределит нагрузку на другие нормально работающие серверы. . начальство.
Масштабировать ваш сервер проще. Все, что вам нужно сделать, это добавить новые серверы в систему балансировки нагрузки. Нет необходимости прерывать ваше приложение.
Так что воспользуйтесь этой возможностью :). Компромисс, конечно, в том, что это потребует немного большей сложности при разработке вашего приложения. Именно об этом и пойдет речь в этой статье.
В этот момент вы можете сказать себе: «Но как мне узнать, что я использую балансировку нагрузки?» '. Самый честный ответ, если вы задаете этот вопрос, заключается в том, что вы, вероятно, не используете систему балансировки нагрузки, и вашей системе не нужно ее учитывать. В большинстве случаев, когда приложение становится достаточно большим, необходимо явно предложить и настроить балансировку нагрузки. Однако время от времени я вижу, как компании веб-хостинга выполняют балансировку нагрузки для клиентских приложений или делают это самостоятельно, как описано ниже.
Прежде чем продолжить, я хотел бы отметить, что в этой статье в основном описывается балансировка нагрузки в PHP. Возможно, я напишу о балансировке нагрузки данных в будущем, но сейчас вам придется подождать.
Обратите внимание, что я продолжаю упоминать «веб-приложения», а не веб-сайты. Это делается для того, чтобы подчеркнуть, что «веб-приложения» — это сложные сайты, которые часто используют серверное программирование и базы данных, а не веб-сайты, которые отображают только простой статический контент.
1. Файлы PHP Первый вопрос: если у вас большое количество небольших серверов, как загрузить файлы PHP на все серверы? К вашему сведению есть следующий метод:
загружать все файлы на каждый сервер отдельно. Проблема с этим методом: представьте, что у вас 20 серверов, тогда это легко приведет к ошибкам в процессе загрузки, а время обновления будет очень большим. быстро Возможно наличие разных версий файлов на разных серверах.
Используйте rsync (или подобное программное обеспечение). Такой инструмент может синхронизировать файлы в локальном каталоге и каталогах на нескольких удаленных хостах.
Используйте программное обеспечение для контроля версий (например, Subversion). Это мой любимый метод. Это позволяет мне очень хорошо поддерживать свой код, и когда я публикую свое приложение, я могу запустить команду обновления svn на каждом сервере для его синхронизации. Этот подход также упрощает переключение серверов на предыдущую версию кода.
Используйте файловый сервер (вы можете обнаружить, что NFS отлично подходит для этого). Этот подход заключается в использовании файлового сервера для размещения вашего веб-приложения. Конечно, если ваш файловый сервер выйдет из строя, все ваши сайты будут недоступны. На этот раз вам нужно будет потратить больше денег, чтобы восстановить его.
Какой метод вы выберете, зависит от ваших потребностей и имеющихся у вас навыков. Если вы используете систему контроля версий, вы можете запланировать обновление кода на всех серверах, одновременно выполнив команду обновления. Однако если вы используете файловый сервер, вам потребуется реализовать некоторый механизм восстановления после сбоя, чтобы предотвратить сбои запросов в случае выхода сервера из строя.
2. Загрузка файлов. При наличии только одного сервера загрузка файлов не является проблемой. Но когда у нас несколько серверов, как следует хранить загруженные файлы? Проблема загрузки файлов аналогична межсерверному хранению файлов PHP. Вот несколько возможных решений:
Сохраните файл в базе данных. Большинство данных позволяют хранить двоичные данные. Когда вы запрашиваете загрузку файла, данные доступа выводят пользователю двоичные данные, а также соответствующее имя и тип файла. Прежде чем использовать это решение, вам следует подумать о том, как база данных будет хранить ваши файлы. Проблема с этим подходом заключается в том, что если сервер базы данных выйдет из строя, файлы станут недоступными.
Храните загруженные файлы на файловом сервере. Как и в предыдущем введении, вам необходимо установить файловый сервер, который будет доступен всем веб-серверам. После загрузки все веб-серверы смогут использовать его. Однако если файловый сервер не работает, загрузка файла изображения может прерываться.
Разработайте собственный механизм загрузки для передачи файлов на каждый сервер. Этот подход не имеет недостатков решения с одним файловым сервером или базой данных, но увеличивает сложность вашего кода. Например, если сервер выйдет из строя во время загрузки на несколько серверов, что вы будете делать?
Использование базы данных для хранения загруженных файлов, но разработка механизма кэширования файлов является хорошим решением. Когда сервер получает запрос на загрузку файла, он сначала проверяет, существует ли файл в системе кэша. Если он найден, он загружает его из системы кэша. В противном случае он считывает его из базы данных и кэширует в файловой системе.
3. Сеансы
Если вы знакомы с обработкой сеансов PHP, вы, вероятно, знаете, что по умолчанию данные сеанса сохраняются во временных файлах на сервере. Причем этот файл находится только на том сервере, где вы его запросили, но последующие запросы могут обрабатываться другим сервером, который сгенерирует новую сессию на другом сервере. Это приводит к тому, что сеансы часто не распознаются, например, вошедшим в систему пользователям всегда предлагается войти в систему снова.
Мое рекомендуемое решение — либо восстановить встроенный в PHP механизм обработки сеансов для хранения данных сеанса в базе данных, либо реализовать собственный механизм, гарантирующий отправку запроса пользователя на тот же сервер.
4. Конфигурация
Хотя эта тема не имеет прямого отношения к PHP, я считаю необходимым упомянуть о ней. При запуске кластерных серверов рекомендуется иметь какой-либо способ синхронизации файлов конфигурации между серверами. Если файлы конфигурации несовместимы, это может привести к очень странному прерывистому поведению, которое будет сложно устранить.
Я рекомендую управлять ими индивидуально, используя систему контроля версий. Таким образом, вы можете хранить разные файлы конфигурации PHP для разных установок проекта, а также синхронизировать все файлы конфигурации сервера.
5. Ведение журнала
Как и проблемы с конфигурацией, ведение журналов связано не только с PHP. Но по-прежнему очень важно поддерживать работоспособность вашего сервера. Без надлежащей системы журналирования как вы узнаете, что ваш PHP-код начинает генерировать ошибки (вы всегда отключаете параметр display_errors, когда система работает, не так ли?)
Есть несколько способов реализовать журналирование
: сервер. Это самый простой способ. Каждая машина записывает только один файл. Преимущество состоит в том, что он прост и может потребовать минимальной настройки. Однако по мере увеличения количества серверов мониторинг файлов журналов на каждом сервере становится очень трудным.
Ведение журнала на общем ресурсе При этом подходе файлы журналов по-прежнему хранятся на каждом сервере, но они хранятся на центральном файловом сервере с помощью механизма общего доступа, что упрощает мониторинг журналов. Проблема с этим решением заключается в том, что если файловый сервер недоступен, простая проблема с записью журнала в конечном итоге приведет к сбою всего приложения.
Ведение журналов на сервере журналов. Вы можете использовать программное обеспечение для журналов, например системный журнал, для записи всех журналов на центральный сервер. Хотя этот метод требует дополнительной настройки, он также обеспечивает наиболее надежное решение.
phpv добавил: Еще один важный момент — управление базами данных, которое может включать в себя много контента. Поэтому автор его не расписал.