Как перейти к масштабируемости для начинающего портала электронной коммерции?

Question

Я хочу масштабировать портал электронной коммерции на основе LAMP.Недавно мы наблюдали огромный всплеск трафика.

Какие шаги (пожалуйста, укажите по порядку) при масштабировании:

1. Стоит ли переходить на Amazon EC2 или аналогичный?какие могут быть потенциальные проблемы при переключении серверов?

2. Нужно ли перепроектировать базу данных?Я прочитал, Facebook переключился на Cassandra от MySql.Какие изменения кода требуются при переключении на Cassandra? Cassandra будет лучшим вариантом, чем MySql?

3. Возможность Hadoop , даже не уверен?

4. Любые другие вещи, о которых нужно подумать?

Считает эту запись полезной.Этот блог также имеет хорошие статьи.То, что я хочу знать, это список шагов, которые я должен учитывать при масштабировании этого приложения.

Answer 1

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

Если вы в настоящий момент запускаете свой веб-сервер и dbms на одном и том же компьютере, вы можете посмотреть, как перенести dbms на выделенный сервер базы данных.

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

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

Если веб-сервер в основном бездействует, а dbms постоянно отключается, нет смысла переключаться на кластер веб-серверов с балансировкой нагрузки.

Сначала позаботьтесь о простых вещах.

Если база данных является вероятным узким местом, убедитесь, что ваша база данных имеет правильные индексы, чтобы она быстро получала время доступа во время поиска и не теряла ненужное время во время обновлений. Удостоверьтесь, что dbms регистрирует другой физический носитель из самих таблиц. Убедитесь, что приложение не выдает бесполезных запросов и т. Д. Убедитесь, что вы не выполняете дорогостоящие аналитические запросы к своей транзакционной базе данных.

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

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

Answer 2

1) Первое - измерьте, сколько запросов в секунду может обслуживать наиболее посещаемые вами страницы.Для хорошо написанных сайтов PHP на среднем оборудовании это должно быть в диапазоне 200-400 запросов в секунду.Если вас там нет - вам нужно оптимизировать код, сократив количество запросов к базе данных, кэшируя редко измененные данные в memcached / shared-памяти, используя PHP-ускоритель.Если вы обрабатываете 10-20 запросов в секунду, вам нужно избавиться от громоздкой платформы.

2) Второе - если вы все еще используете Apache2, вам нужно переключиться на lighthttpd или nginx + apache2.Лично мне нравится второй вариант.

3) Затем вы перемещаете все свои статические данные на отдельный сервер или CDN.Убедитесь, что он подается с заголовками «expires», по крайней мере, 24 часа.

4) Только после всего этого вы можете подумать о переходе на EC2 / Hadoop, построении нескольких серверов и балансировке нагрузки (nginxтакже там вам помогут)

После шагов 1-3 вы сможете легко обслуживать около 10 000 000 ударов в день.

Если вам нужно всего лишь в 1,5-3 раза больше, япойдет на один более мощный сервер (8-16 ядер, много оперативной памяти для кэширования и базы данных).

С шагом 4 и несколькими серверами вы достигнете 0,1-1 миллиарда обращений в день (но значительнобольшие расходы на оборудование и поддержку).

Answer 3

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

Если вы недавно видели взрыв трафика, проанализируйте, какие страницы медленнее.

1. Вы можете перейти в облако, но EC2 - не самая эффективная.Опять же, убедитесь, что нет никакой другой оптимизации, которую вы можете сделать.

2. База данных может быть изменена, но я сомневаюсь во всем этом.Опять же, посмотрите на проблемные моменты.

3. И Хэдуп, и Кассандра довольно изящны, но они могут быть излишними.

Answer 4

Узнайте, где возникают проблемы (или они могут возникнуть, если у вас их нет сейчас). Знание того, какое использование ресурсов является вашим наибольшим, важно при оценке любого решения. Придерживайтесь решений, которые дадут вам самое большое улучшение.

Рассмотрим: - использование полосы пропускания выше необходимой x пользователь - это то, к чему вы хотите обратиться независимо от перехода на ec2. В любом случае это будет стоить вам денег, так что стоит взглянуть на такие вещи: http://developer.yahoo.com/yslow/ - не вкладывайте средства в изменение баз данных, если это не проблема. Сначала выясните, действительно ли это проблема, и даже если у вас возникли проблемы с базой данных, это может быть проблема с кодом, то есть попадание в базу данных много раз за запрос. - если мы не говорим о v. больших числах, у вас не должно быть проблем с высоким использованием процессора, если вы узнаете, где они происходят, или оптимизация того стоит, когда конкретный код оказывает большое влияние на общее использование ресурсов. - убедившись, что вышеприведенное является разумным, вы можете получить значительные улучшения в кешировании. В полосе пропускания (обеспечение того, чтобы браузеры / прокси-сервер могли играть свою роль при кэшировании), использование локальных ресурсов (избегая повторной обработки / повторного получения одной и той же информации все время).

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