Основанное на Java веб-приложение для транзакций большого объема

Question

У меня почти нет опыта работы с большими объемами транзакционных сайтов, и недавно я столкнулся с этим интересным вопросом. Мне интересно знать, где возникают узкие места в веб-приложении Java при высокой нагрузке (тысячи запросов в секунду). Если бы кто-то мог дать мне подход высокого уровня к размышлению над следующим вопросом, это было бы здорово!

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

Вопрос: Интернет-приложения должны быть рассчитаны на обработку больших объемов транзакций. Опишите схему системы, которая должна обрабатывать в среднем 30 000 HTTP-запросов в секунду. Для каждого запроса система должна выполнить поиск в словаре из 50 миллионов слов, используя ключевое слово, переданное через строку запроса URL. Каждый ответ будет состоять из строки, содержащей определение слова (не более 100 байт).

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

Документируйте обоснование при составлении сметы.

Опишите, как изменился бы дизайн, если бы определения составляли 10 килобайт каждое.

Answer 1

В качестве фона вы можете отметить bechmarks, такие как specmarks. По сравнению с вашим сценарием значительно больше обработки, но вы увидите, что ваши 30 000 запросов в секунду - это сравнительно высокая, но не безумно высокая цифра.

Вы также можете найти полезным Joines et al. (Отказ от ответственности: они коллеги.)

В вашем сценарии я бы ожидал в порядке убывания стоимости:

1. Поиск в базе данных
2. Сетевая активность чтения и возврата запросов
3. Простая обработка

Вы не делаете сложную обработку (например, рендеринг графики или математика типа ракетостроения). Итак, первое предположение: если ваш словарь был базой данных, тогда стоимость выполнения запроса будет доминировать над всем остальным. Традиционно, когда мы сталкиваемся с узкими местами на уровне сервера Web/App, мы масштабируемся, добавляя больше экземпляров, но если база данных является узким местом, это больше проблем. Итак, одно направление: какую производительность вы можете ожидать от механизма базы данных, кажется ли это возможным при 30 тыс. Т / с?

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

50 000 000 * (100 + накладные расходы) ==??

На 64-битной JVM на 64-битной ОС, может быть, подходит?

Если нет (а поскольку данные становятся действительно большими, то, вероятно, нет), то нам нужно масштабировать. Следовательно, может быть использована стратегия нарезки кэша. Имейте (например) 4 сервера, обслуживающих AF, GM, NP, TZ соответственно (и, обратите внимание, 4 отдельных кэша или 4 отдельных базы данных). Есть диспетчер, направляющий запросы.

Answer 2

Первое, что я хотел бы сделать, это поставить под сомнение цифры. В английском языке около 170 000 слов общего пользования. Добавьте все остальные распространенные языки, и у вас будет не более пары миллионов. Если это не так, вы можете кэшировать наиболее распространенные слова в быстром кеше и менее распространенные слова в более медленном. Даже при запросе 30K в секунду, для получения каждого незаполненного слова потребуется около 30 минут.

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

На 64-битной JVM это легко устанавливается. 50 миллионов * (100 + накладные расходы) - около 10 ГБ (издержки равны значительным, так как вам нужен ключ и индексирование данных). Сервер на 12 ГБ стоит около 2500 долларов.

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