Причина, по которой я спрашиваю, это то, что переполнение стека было Dugg, Slashdotted и Redditted.Какие технические соображения должен беспокоить системный/сетевой администратор, когда сайт попадает на сайты социальных закладок или обмена?
Во-первых, какой эффект оказывает это на серверах, которые используют веб-сайт? Во-вторых, что могут сделать системные администраторы, чтобы обеспечить их работу и работу как можно лучше?
К сожалению, если вы еще не планировали этого, прежде чем это произойдет, возможно, слишком поздно, и у ваших пользователей будет плохой опыт.
Масштабируемость - это ваша первая непосредственная проблема. Вы можете начать получать больше ударов в секунду, чем вы получали в месяц. Ваша первая линия обороны - хорошее программирование и дизайн. Убедитесь, что вы не делаете ничего глупого, как перезагрузка данных из базы данных несколько раз за запрос, а не кеширование. Прежде чем всплеск произойдет, вам нужно провести довольно реалистичные тесты нагрузки, чтобы увидеть, где узкие места.
Для абсурдно большого трафика рассмотрите возможность переключения некоторых динамических страниц на статические страницы.
Наличие архитектуры сервера, которая может масштабироваться, также помогает. Общие хосты обычно не масштабируются. Отдельная специализированная машина обычно не масштабируется. Использование чего-то вроде EC2 в Amazon может помочь, особенно если вы планируете кластер серверов с самого начала (даже если ваш кластер является единственным компьютером).
Вы в первую очередь обеспокоены безопасностью. Вы внезапно становитесь гораздо более крупной целью для плохих парней. Убедитесь, что у вас есть хороший план безопасности. Это то, что вы всегда должны иметь, но оно становится более важным с высоким уровнем использования.
Во-первых, спросите, действительно ли вы хотите потратить недели и тысячи долларов на планирование чего-то, что может даже не произойти, и если это произойдет, длится около 5 часов.
Самое простое решение - иметь хороший способ перейти на страницу, просто разрешив регистрацию. Люди будут подписаны, и вы можете отправить их по электронной почте, когда шторм прошел.
Более сложные решения полагаются на возможность быстрого масштабирования. Это, во-первых, проблема с программным обеспечением (вы можете подключиться к db на другом сервере, можете ли вы выполнять балансировку нагрузки). Во-вторых, ваше хостинг-решение должно поддерживать быстрое расширение. Amazon EC2 приходит на ум, или, может быть, slicehost. С помощью обеих служб вы можете легко запускать новые экземпляры («Давайте переместим базу данных на другой сервер») и расширим ваши экземпляры («Давайте обновим сервер db до 4 ГБ ОЗУ»).
Если вы сохраняете все данные в db (включая сеансы), вы можете легко иметь несколько интерфейсных серверов. Для базы данных я обычно пытаюсь использовать один сервер с самыми доступными ресурсами, но только потому, что я не работал с репликацией db, и это было довольно сложно сделать, по крайней мере, с mysql. Возможно, ситуация улучшилась.
Разработчик приложения должен думать о масштабировании (более крупные машины с большим количеством ядер и более высокой производительности) и/или масштабировании (распределение рабочей нагрузки по нескольким системам). IT-менеджер должен решить, как наилучшим образом поддержать это. Сеть - это то, на что вы смотрите в первую очередь, потому что, очевидно, все проходит поверх нее. Начиная с границы, это обычно означает, что балансиры сетевой нагрузки и избыточные маршрутизаторы обслуживаются несколькими провайдерами. Вы также можете посмотреть географические службы кеширования и приложения, такие как cachefly.
Вы хотите как можно меньше уменьшить свои узкие места.Вы также хотите создать среду, чтобы ее можно было масштабировать по мере необходимости без большой работы. Проработайте дизайн спереди, и это будет означать меньше головных болей, когда вы будете получать dugg.
Некоторые идеи (из того, что я использовал в прошлом и текущих проектах): Для повышения производительности (при необходимости) вы можете поставить обратный прокси-кеширующий кальмар перед вашим сервером. Конечно, это работает только в том случае, если у вас нет ключей сеанса, и если страницы несколько статичны (означает: они меняются только один раз в час), а не персонализированные. С кальмаром вы можете увеличить раздутую и медленную CMS, такую как typo3, тем самым имея производительность статических сайтов с комфортом CMS.
Вы можете передавать большие файлы внешним сервисам, таким как Amazon S3, сохраняя пропускную способность вашего сервера.
И если вы можете потратить несколько (три цифры в месяц) долларов, вы также можете использовать Сеть доставки контента. При этом вы автоматически используете масштабирование, высокую доступность и низкие latencys для своих пользователей. Конечно, ваши страницы должны быть кэшируемыми, поэтому сеансовые ключи и персонализированные страницы - нет-нет. Если вы разрабатываете тщательно и с учетом CDN, вы можете, по крайней мере, кэшировать НЕКОТОРЫЙ контент, например, фотографии и видеоролики и статические вещи.
Нагрузка повышается, как упоминалось в других ответах.
Вы также получите приток новых пользователей/комментариев блога/голосов от скучающих людей, которые действительно заинтересованы только в вандализме. Это в основном проблема для блогов, которые позволяют полностью анонимный комментарий, где будут введены некоторые ужасные вещи. Платформа для блога может иметь фильтры спама, достаточные для ее блокировки, но часто требуется ручное вмешательство, чтобы очистить оставшуюся дрожь.
Даже небольшой барьер для входа, например, требующий имени пользователя или адреса электронной почты, даже если проверка не будет выполнена, значительно уменьшит объем вандализма.