Стек решений с открытым исходным кодом для высокопроизводительного веб-сайта? - PullRequest
3 голосов
/ 08 марта 2009

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

Некоторые попытки определения:

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

  • Производительность: представьте себе веб-сайт, который может обрабатывать миллионы пользователей, сотни терабайт данных (HTML, изображения, видео и т. Д.), Тонны трафика каждый день, время безотказной работы 99,99% в год.

Стек решения должен по крайней мере указывать:

  • OS
  • веб-сервер
  • база данных или эквивалент
  • язык программирования

При необходимости вы также можете предложить другие программы, библиотеки, инструменты и т. Д. (Например, библиотеки для конкретных языков, балансировщики нагрузки, кэширование).

Ответы [ 3 ]

3 голосов
/ 08 марта 2009

При разработке высокопроизводительного и масштабируемого сайта существует ряд ключевых областей:

  1. кэширование
  2. Дисковый ввод-вывод и местоположение
  3. Блокировка базы данных
  4. Я упоминал о кешировании?

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

Для кэширования контента вы должны посмотреть: Squid, Apache mod_cache и memcached

Физические диски должны быть рассмотрены. Если вы масштабируете свое решение, имея более одного веб-сервера, то вы будете делиться одной копией своего контента (видео, изображений и т. Д.) Или у вас будет одна копия для каждого сервера? Если вы используете одну копию, остерегайтесь ввода-вывода на этом диске. Если у вас есть одна копия содержимого для каждого сервера, вам нужно синхронизировать копии.

Использование базы данных должно быть сведено к минимуму. Никогда, никогда не храните графику в базе данных или другой контент, который можно хранить в виде простого файла на диске - веб-серверы отлично справляются с обслуживанием файлов с диска, но базы данных не так хороши для этого. Подумайте, что вам нужно , чтобы поместить в вашу базу данных, и как часто эти данные будут меняться и читаться. Когда вам нужно заблокировать эту базу данных? 9 раз из 10 база данных является узким местом в системе.

Cache. Кэш. Кэш. Посмотрите на доставку как можно большего количества статического контента. Создайте HTML-код своей веб-страницы один раз, а затем сохраните его в виде кэшированного файла - либо на диске, либо в memcached или аналогичном.

Чтобы ответить на некоторые ваши технологические вопросы напрямую:

Веб-сервер - это дано: Apache Httpd. Не самый быстрый, но пуленепробиваемый и легко настраиваемый.

ОС: Ваша ОС никогда не станет вашим узким местом, поэтому выберите что-то стабильное и хорошо поддерживаемое - CentOS работает хорошо.

DB: Ваш очевидный выбор - MySQL и Postgres. Postgres имеет лучшую производительность, но, как я уже говорил, вы должны стараться свести к минимуму активность вашей БД.

Язык: не имеет значения. Шутки в сторону. Вы можете создать масштабируемый, хорошо работающий сайт на любом из Python, Ruby, PHP, Java, .NET и т. Д. Ваш язык не будет вашим узким местом.

2 голосов
/ 08 марта 2009

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

1 голос
/ 08 марта 2009

У меня есть рекомендация для веб-сервера для вас:

nginx [двигатель х]

На своем веб-сайте , а также в других уголках Интернета вы можете получить дополнительную информацию о нем, в том числе о популярных веб-сайтах, использующих его. Очень хороший пример - Hulu.com, работающий с большим количеством потокового видео. Говорят, что он работает лучше, чем lighttp, типичный конкурент Apache, когда речь идет о сырой производительности.

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

...