Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Java EE (J2EE) и Spring > java in memory queue

Автор: Samotnik 11.2.2015, 19:02

Привет. Есть веб сервис, который принимает пачки запросов, он ложит их в очередь (in memory) и затем по одному берет и обрабатывает. Всё ок. Сейчас встал вопрос о том, что если с серваком будет что-то не так, то все пропадет и решили хранить в БД.  Вопрос, что выбрать? Все что приходит в голову это jms или другой Message Brocker. Еще варианты? может поможет java queue executor? Может кто-то реально такую задачу делал, какие есть варики? Естетсвенно условий два, как можно проще и производительность не упала

Автор: Kircul 11.2.2015, 21:27

Вообще уже есть готовые сервисы которые выполняют описанную выше задачу. Например: https://github.com/gresrun/jesque (ничего не могу сказать про качество прорта на Java, я работал с оригинальным проектом на Ruby: https://github.com/resque/resque). Сам сталкивался с этой задачей года 3 назад. Мы писали свой сервис с сохранением в MongoDB. Нам нужна была приоритизация задач, распределенное выполнение и резервирование выполняющих потоков. Найти сервис удовлетворяющий всем этим требованиям не удалось.

Автор: AntonSaburov 16.2.2015, 09:07

IMHO - jms вполне приличное решение.

Автор: Samotnik 17.2.2015, 15:23

два больших, очевидных минуса ms: 1- невозможно соблюсти порядок в очереди, а это очень важно в рамках таска. 2 - сами данные довольно большие, может доходить по тысячи объектов с 10 полями. Разве он справится? На сколько я помню в body можно положить только текстовую небольшую информацию.

Автор: AntonSaburov 17.2.2015, 17:27

1. Порядок решается вариантом размещения дампа времени в сообщение - кто раньше отправил, тот и прав. 2. Нормальный JMS может файлы по несколько мегабайт передавать вполне пристойно. И большое количество - это как раз нормально. У нас на таком механизме весьма нагруженные системы работают.

Автор: Samotnik 17.2.2015, 17:59

Цитата(AntonSaburov @  17.2.2015,  17:27 ) 1. Порядок решается вариантом размещения дампа времени в сообщение - кто раньше отправил, тот и прав. может я что не так понял. https://en.wikipedia.org/wiki/Java_Message_Service Цитата JMS queue     A staging area that contains messages that have been sent and are waiting to be read (by only one consumer). Note that, contrary to what the name queue suggests, messages don't have to be received in the order in which they were sent. A JMS queue only guarantees that each message is processed only once.

Автор: AntonSaburov 17.2.2015, 19:52

Так тут вопрос возникает - есть такое требование, чтобы с одной стороны в базу (или еще куда) укладывалось очень быстро (и желательно асинхронно), а с другой стороны, чтобы в соответствии со временем "укладывания" обрабатывалось ? Тогда надо задачу точнее сформулировать: Нужно ли обрабатывать запросы синхронно или их обработку можно отложить и отдельным потоком обрабатывать уже с учетом времени "укладывания" в базу. Можно так - сначала положили с дампом времени одним потоком (через JMS), а потом другой поток делает обработку. Выбирает те, которые легли уже какое-то время назад, чтобы брать не самые свежие, которые еще могут быть перепутаны из-за задержки, а с запасом.

Автор: Tony 10.3.2015, 17:46

Топикстартер, посмотрите Hazelcast.

Автор: mbasil 13.3.2015, 16:59

1. В JMS сообщения помимо текстовых могут иметь и такие типы: MapMessage    Объект содержащий пары ключ-значение, например HashMap BytesMessage    Поток не интерпретируемых системой байтов, двоичные данные  StreamMessage    Потоковые данные,  читаемые последовательно ObjectMessage    Сериализованный Java объект Cериализация работает вполне пристойно. 2. Порядок обработки можно обеспечить легко, задав прзнак порядка, например числовой номер сообщения и код группы, а также общее количество. Все сообщения сохраняются в промежуточном хранилище до прибытия непрерывной последовательности ряда. Каждый обработчик должен проверять не получен ли полный набор и, при получении, делается окончательная обработка всех сообщений от первого до последнего в нужном порядке.  3. При включении постоянства JMS провайдер обязан гарантировать доставку даже в случае сбоев, а это весьма недурственно.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)