Назад | Перейти на главную страницу

правильная архитектура серверов для большого приложения facebook?

Мы группа из 3 студентов, мы создали приложение facebook с более чем 753 320 активных пользователей прямо сейчас, приложение размещено на сервере LAMP 1 & 1:

- AMD Opteron 1352 4 x 2,1 GHz
- 4 GB RAM.
- 2 x 750 Go (RAID 1 Hardware).
- Connection : 100 Mbps.

Это приложение работает очень хорошо, без проблем.

Мы готовим новое приложение и через несколько месяцев ожидаем миллионы активных пользователей.

Информация о приложении:

Мы хотим знать правильную архитектуру для этого сервера приложений.

Удаленный сервер MySQL и статические файлы на каждом сервере с одинаковой конфигурацией.

Может ли приложение обрабатывать миллионы запросов ежедневно?

Заранее спасибо.

Любые ответы, которые вы получите, будут безумными предположениями. Вам действительно необходимо провести надлежащее нагрузочное тестирование вашего приложения с реалистичными данными и шаблонами использования на всем протяжении всего аппаратного и программного стека. Используйте числа из вашего нагрузочного теста, чтобы составить план масштабируемости и оценки стоимости. Ничто не масштабируется идеально линейно, особенно на уровне базы данных, поэтому есть некоторые догадки, даже когда у вас есть точные числа, и вы можете столкнуться с «стеной» в конкретном компоненте (например, в базе данных). Начать с JMeter, который может захватывать сеансы HTTP для создания нагрузки. Коммерческие инструменты намного более эффективны, но также очень дороги.

Не зная, что именно вы делаете, невозможно дать железный совет. Однако скажу так:

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

За не очень большие деньги вы можете арендовать кучу маленьких VPS у Slicehost, Linode, Rackspace Cloud и т. Д. Через шесть месяцев, когда вы добьетесь невероятного успеха, вы сможете арендовать / купить собственное оборудование и запустить собственную виртуализацию, или придерживаться своего поставщика, или перейти на «настоящие» серверы, или что-то еще. Но если вы думаете, что вам когда-нибудь понадобится более одного сервера, запрограммируйте свое приложение на кластерную установку. По стоимости вашего выделенного бокса вы можете запустить 10 «игрушечных» серверов.

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

Если вы посмотрите на свои требования и решите, что однажды вам может понадобиться запускать сегментированные базы данных mysql, вы можете смоделировать это сейчас с помощью недорогих VPS.

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

То же самое касается настройки нескольких серверов / балансировщиков для обслуживания статического контента (или вы можете пойти по маршруту s3 / cloudfront).

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

Я бы сказал, что с учетом размера пользовательской базы наиболее важной частью архитектуры здесь является кэширование и возможность простого масштабирования по запросу. Просто посмотрите на Facebook и подумайте на секунду, в 2009 году ежедневный прирост данных составлял 12 ТБ! да ежедневно.

Что касается MySQL,

  1. mysqltuner является обязательным условием для любой коробки.
  2. Slow Query Log поможет вам перейти на более производительное приложение.
  3. Включение общего журнала (КРАТКО) может быть хорошим делом, затем запустите EXPLAIN для всех ваших запросов, чтобы убедиться, что у вас есть правильная индексация (отсутствие покрытия, хорошая мощность и т. Д.)
  4. Вы ведете сеанс в базе данных? Не делайте этого, если вы можете этого избежать, но если нет, подумайте о таблице MEMORY.
  5. Говоря о типах таблиц, рассмотрите фактическое использование каждой таблицы. Транзакционные таблицы с высокими потребностями чтения / записи могут быть лучше в механизме хранения InnoDB. Таблицы, которые преимущественно пишут или read лучше всего использовать как MyISAM. Вы тоже заходите в базу данных? Рассмотрим механизм ARCHIVE для этих таблиц.