Масштабируемость приложения Java EE. Как бы вы подошли к этому?

Question

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

Входные файлы представляют собой отформатированные в формате XML большие (более сотни мегабайт) сообщения, содержащие много повторяющихся записей. Постоянное хранилище - это реляционная база данных. Движок реализован в виде приложения Java на основе POJO (Spring Framework в качестве основы), развертываемого на сервере приложений J2EE.

Вопрос касается масштабируемости и производительности решения. Если приложение последовательно обрабатывает записи из XML, масштабируемость решения довольно низкая. нет способа задействовать более одного экземпляра приложения для обработки одного файла. Вот почему я ввел параллельную обработку для записей из входного XML-файла. По сути, идея состоит в том, чтобы отправить обработку отдельных записей для работников из пула. Я решил использовать JMS для отправки. Компонент, который загружает файл, читает поток и просто извлекает отдельные записи и передает очередь отправки. На другом конце очереди находится ряд одновременных потребителей. Каждый выбирает одно сообщение из очереди и обрабатывает запись, и она сразу же доступна для обработки другой записи. Это очень похоже на сервлеты в веб-контейнере. Что мне показалось особенно мощным в этом подходе, так это то, что работники могут находиться в отдельных экземплярах приложения, развернутого на удаленных серверах, до тех пор, пока очередь является общей. К сожалению, все работники подключаются к одной и той же базе данных, которая поддерживает постоянное хранилище, и это может стать узким местом, если сервер баз данных не достаточно мощный, чтобы справиться с нагрузкой от одновременных работников.

Что вы думаете об этой архитектуре? У вас было похожее приложение для дизайна? Какой был твой дизайн тогда?

Answer 1

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

Answer 2

Я думаю, что архитектура в целом здорова. Если у базы данных возникают проблемы с большим количеством одновременных обновлений от рабочих, вы можете ввести 2-ю очередь на другой «стороне» приложения: по мере того, как каждый работник завершает свою задачу, они добавляют результаты этой задачи в очередь. Затем один рабочий процесс периодически извлекает объекты результатов из 2-й очереди и обновляет базу данных в крупной пакетной операции? Это уменьшит параллелизм в базе данных и может повысить эффективность обновлений.

Answer 3

Недавно я провел свободное время, исследуя Spring Batch 2.0. Это новая версия Java-движка, основанного на Spring Framework. Ребята, которые внедрили Spring Batch, сконцентрировались на параллелизме и распараллеливании исполнения для этого выпуска Надо сказать, это выглядит многообещающе!

Answer 4

Для параллельной обработки, как сказал Mork0075, hadoop - отличное решение. На самом деле многие компании используют его для очень большого анализа журнала. И интересный проект Hive был построен на основе hadoop для хранилищ данных.

Во всяком случае, я думаю, что ваш текущий дизайн довольно масштабируемый. Что касается вашего беспокойства о том, что все работники попадают в базу данных, вы можете просто поставить еще одну очередь сообщений между работниками и базой данных. Рабочие помещают результаты обработки в очередь, а вы создаете другую программу для подписки на очередь и обновления базы данных. Недостатком является то, что две очереди могут сделать систему слишком сложной. Конечно, вы можете просто добавить еще одну тему в существующую систему MQ. Это сделает систему проще. Другой подход заключается в использовании общей файловой системы, такой как NFS, каждый рабочий компьютер монтирует один и тот же каталог на общем файловом сервере, и каждый рабочий записывает результаты своей обработки в отдельный файл на общем файловом сервере. Затем вы создаете программу для проверки новых файлов для обновления базы данных. В этом подходе вы вводите другую сложность: общий файловый сервер. Вы можете судить, какой из них проще в вашем случае.

Answer 5

Кроме того, взгляните на кластерное решение Terracota.

Answer 6

В ответ на ваши вопросы:

Что вы думаете об этой архитектуре? У вас было похожее приложение для дизайна? Какой был твой дизайн тогда?

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

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

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

Answer 7

Если вы уже используете Spring / Java EE, естественно использовать Spring Batch в качестве решения для вашей «архитектуры параллелизма».

Два преимущества справа от летучей мыши:

1. В Spring Batch (начиная с 2.0) реализовано разбиение, это означает, что среда позаботится о том, чтобы разделить данные для вас на отдельных этапах разбиения (StepExecution) и делегировать фактическое выполнение этих этапов нескольким потокам или другие распределенные системы (PartitionHandlers, например TaskExecutorPartitionHandler или более распределенные MessageChannelPartitionHandler и т. д.)

2. Spring имеет хороший пакет OXM для работы с XML + Spring Batch имеет StaxEventItemReader, который извлекает фрагменты из входного XML-документа, которые соответствуют записям для обработки

Дайте Spring Batch попробовать. Дайте мне знать, если у вас есть какие-либо вопросы, я буду рад помочь.

EDIT:

Также посмотрите на Scala/AKKA Actors и / или Scala parallel collections. Если ваша задача применима для разбиения / разделения / распределения => для чего предназначена модель Actor.

Если вы хотите рассмотреть решение, не относящееся к JVM, взгляните на Erlang OTP => просто и элегантно.