Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Горизонтальное масштабирование PHP приложений. Часть 1

Anna | 29.05.2014 | нет комментариев

Выходит вы сделали сайт. Неизменно увлекательно и волнительно следить как счетчик посещений медлительно, но правильно ползет вверх, с всяким днем показывая все лучшие итоги. Но некогда, когда вы этого не ожидаете, кто-то запостит ссылку на ваш источник на каком-нибудь Reddit либо Hacker News (либо на Прогре — прим. пер.), и ваш сервер ляжет.

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

Немножко про оптимизацию

Основные советы каждому вестимы: обновитесь до последней версии PHP (в 5.5 сейчас встроен OpCache), разберитесь с индексами в базе данных, кэшируйте статику (редко изменяемые страницы, такие как “О нас”, “FAQ” и т.д.).

Также стоит упомянуть об одном специальном аспекте оптимизации — обслуживании статического контента не-Apache сервером, таким как, скажем, Nginx, Настройте Nginx на обработку каждого статического контента (*.jpg, *.png, *.mp4, *.html…), а файлы требующие серверной обработки пускай отсылает тяжелому Apache. Это именуется reverse proxy.

Масштабирование

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

Вертикальное масштабирование.

Представьте себе сервер, обслуживающий веб-приложение. У него 4ГБ RAM, i5 процессор и 1ТБ HDD. Он отменно исполняет свои функции, но, что бы отменнее справляться с больше высоким трафиком, вы решаете увеличить RAM до 16ГБ, поставить процессор i7, и раскошелиться на SSD диск. Сейчас сервер значительно мощнее, и справляется с высокими нагрузками. Это и есть вертикальное масштабирование.

Горизонтальное масштабирование.

Горизонтальное масштабирование — создание кластера из связанных между собой (Зачастую не дюже сильных) серверов, которые совместно обслуживают сайт. В этом случае, применяется балансировщик нагрузки (aka load balancer) — машина либо программа, основная функция которой — определить на какой сервер послать запрос. Сервера в кластере делят между собой обслуживание приложения, ничего друг о друге не зная, таким образом гораздо увеличивая пропускную способность и отказоустойчивость вашего сайта.

Есть два типа балансировщиков — аппаратные и программные. Программный — устанавливается на обыкновенный сервер и принимает каждый трафик, передавая его соответствующим обработчикам. Таким балансировщиком может быть, скажем, Nginx. В разделе “Оптимизация” он перехватывал все запросы на статические файлы, и обслуживал эти запросы сам, не обременяя Apache. Другое знаменитое ПО для реализации балансировки нагрузки — Squid. Лично я неизменно использую именно его, т.к. он предоставляет чудесный дружелюбный интерфейс, для контроля за самыми большими аспектами балансировки.

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

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

Непрерывное соединение

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

Обмен локальными данными.

Поделить данные сессии пользователей между всеми нодами кластера — кажется недурной идеей. И невзирая на то, что данный подход требует некоторых изменений в архитектуре вашего приложения, оно того стоит — разгружается балансировщик, и каждый кластер становится больше отказоустойчивым. Гибель одного из серверов абсолютно не отражается на работе каждой системы.
Как мы знаем, данные сессии хранятся в суперглобальном массиве $_SESSION, тот, что пишет и берет данные с файла на диске. Если данный диск находится на одном сервере, видимо, что другие сервера не имеют к нему доступа. Как же нам сделать его доступным на нескольких машинах?
Во первых, обратите внимание, что обработчик сессий в PHP дозволено переопределить. Вы можете реализовать свой личный класс для работы с сессиями.

Применение БД для хранения сессий

Применяя личный обработчик сессий, мы можем беречь их в БД. База данных может быть на отдельном сервере (либо даже кластере). Традиционно данный способ отменно работает, но при подлинно большом трафике, БД становится тесным местом (а при потере БД мы всецело теряем работоспособность), потому как ей доводится обслуживать все сервера, всякий из которых пытается записать либо прочитать данные сессии.

Распределенная файловая система

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

Memcached

Вы также можете применять memcached для хранения данных сессий в RAM. Впрочем это не неопасно, потому как данные в memcached перезаписываются, если заканчивается свободное место. Вы, вероятно, задаетесь вопросом, разве RAM не поделен по машинам? Как он используется на каждый кластер? Memcached имеет вероятность объединять доступную на различных машинах RAM в один пул.

Чем огромнее у вас машин, тем огромнее вы можете отвести в данный пул памяти. Вам не непременно объединять всю память машин в пул, но вы можете, и вы можете пожертвовать в пул произвольное число памяти с всякой машины. Так что, есть вероятность оставить большую часть памяти для обыкновенного применения, и выделить кусок для кэша, что дозволит кэшировать не только сессии, но иную подходящую информацию. Memcached — чудесное и обширно распространенное решение.

Для применения этого подхода, необходимо немножко подредактировать php.ini

session.save_handler = memcache
session.save_path = "tcp://path.to.memcached.server:port"
Redis кластер

Redis — NoSQL хранилище данных. Хранит базу в оперативной памяти. В различие от memcached поддерживает непрерывное хранение данных, и больше трудные типы данных. Redis не поддерживает кластеризацию, так что применять его для горизонтального масштабирования несколько затруднительно, впрочем, это временно, и теснее вышла альфа версия кластерного решения.

Другие решения

ZSCM недурная альтернатива от Zend, но требует Zend Server на всякой ноде.
Если вас волнуют другие NoSQL хранилища и системы кэширования — испробуйте ScacheCassandra либоCouchbase.

Итого

Как видите, горизонтальное масштабирование PHP приложений не такое уж примитивное дело.

Источник: programmingmaster.ru

 

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB