Основанное на Java веб-приложение крупной транзакции
Я не имею рядом ни с каким опытом, имеющим дело с большим объемом транзакционные веб-сайты, и недавно столкнулся с этим интересным вопросом. Я интересуюсь знанием, где узкие места в веб-приложении Java произошли бы при высокой загрузке (тысячи запросов в секунду). Если бы кто-то мог бы дать мне подход высокого уровня к размышлению о следующем вопросе, который был бы большим!
Единственная вещь, которую я придумал, состоит в том, чтобы использовать memcached для кэширования поисков базы данных, но я не знаю, как вычислить количество времени, которое каждый запрос займет и поэтому сколько запросов в секунду система смогла обрабатывать.
Вопрос: приложения интернет-масштаба должны быть разработаны для обработки больших объемов транзакций. Опишите дизайн для системы, которая должна обработать в среднем 30 000 Запросов HTTP в секунду. Для каждого запроса система должна выполнить поиск в словарь 50 миллионов слов, с помощью ключевого слова, переданного на пути строка запроса URL. Каждый ответ будет состоять из строки, содержащей определение слова (100 байтов или меньше).
Опишите главные компоненты системы и примечание, какие компоненты должны быть произведены по заказу и какие компоненты могли усилить сторонние приложения. Включайте аппаратные оценки для каждого компонента. Обратите внимание на то, что дизайн должен включать максимальную производительность в минимальные аппаратные средства / затраты на лицензирование программного обеспечения.
Зарегистрируйте объяснение в предложении оценок.
Опишите, как дизайн изменился бы, если определения составляют 10 килобайтов каждый.
2 ответа
Первое, что я сделаю, это поставлю под сомнение цифры. В английском языке используется около 170 000 слов. Добавьте все остальные распространенные языки, и у вас будет не более пары миллионов. Если это не так, вы можете кэшировать наиболее часто встречающиеся слова в быстром кеше и менее распространенные слова в более медленном кеше. Даже при запросе 30 КБ в секунду на получение каждого уникального слова потребуется около 30 минут.
По сути, нет смысла разрабатывать большую систему, если числа не реальны.
На 64-битной JVM это легко умещается. 50 миллионов * (100 + накладные расходы) составляют около 10 ГБ (накладные расходы вроде бы высоки, поскольку вам нужно иметь ключ и индексировать данные). Сервер на 12 ГБ стоит около 2500 долларов.
Проблема в количестве запросов. Вам понадобится несколько машин, но, как предполагают другие плакаты, цифры вряд ли будут реальными. Я не думаю, что эта услуга будет такой же дорогой, как facebook, но вам, вероятно, понадобятся от десятков до сотен серверов для поддержки такого количества запросов.
В качестве фона вы можете обратить внимание на bechmarks, такие как specmarks. По сравнению с вашим сценарием там значительно больше обработки, но вы увидите, что ваши 30 000 запросов/сек - это сравнительно высокая, но не безумно высокая цифра.
Вы также можете найти Joines et al полезными. (Оговорка: они коллеги.)
В вашем сценарии я бы ожидал в порядке убывания стоимости:
- Поиск в базе данных
- Сетевая активность, чтение и возврат запросов
- Простая обработка
Вы не занимаетесь сложной обработкой (например, графическим рендерингом или математикой типа "ракетная наука"). Итак, первое предположение: если ваш словарь - это база данных, то стоимость выполнения запроса будет доминировать над всем остальным. Традиционно, когда мы сталкиваемся с узкими местами на уровне серверов Web/App, мы масштабируем их путем добавления дополнительных экземпляров, но если узким местом является база данных, то это еще большая проблема. Итак, одно направление: какой производительности вы можете ожидать от движка базы данных, кажется ли 30k tps выполнимым?
Ваше первое наблюдение: кэширование - это часто используемая стратегия. Здесь у вас (предположительно) случайные совпадения по всему словарю, поэтому само по себе кэширование недавних аскриптов, вероятно, не поможет, если только... вы не можете кэшировать все?
50,000,000 * (100 + накладные расходы) == ?
На 64-битной JVM на 64-битной ОС, возможно, это подходит?
Если нет (а поскольку данные становятся очень большими, то, вероятно, нет), тогда нам нужно масштабирование. Следовательно, можно использовать стратегию нарезки кэша. Например, 4 сервера, обслуживающие A-F, G-M, N-P, T-Z соответственно (и, заметьте, 4 отдельных кэша или 4 отдельных базы данных). Пусть диспетчер направляет запросы.