Меня попросили спроектировать и внедрить систему для получения большого объема данных автоматизированного датчика с большого количества устройств. Эти данные будут создаваться через регулярные промежутки времени и отправляться на сервер в виде XML в сообщении http. Устройства будут повторно отправлять одни и те же данные, если они не получат определенного подтверждения от сервера. Некоторая потенциально тяжелая обработка этих данных должна произойти до того, как они будут вставлены в ряд таблиц в основной базе данных посредством транзакции, и, кроме того, некоторые точки данных должны быть поставлены в очередь для перенаправления на другие внешние URL-адреса.
Я планирую использовать сервер приложений Java (в сторону GlassFish) с сервлетом для получения входящих данных. Я хотел бы реализовать какой-либо механизм организации очередей для временного хранения данных, чтобы ответная реакция на датчик не зависела от всей промежуточной обработки. Отдельные независимые очереди также являются требованием для переадресации данных. После некоторых исследований, два основных варианта выглядят так:
1) Установите базу данных на сервере приложений и используйте таблицы для различных очередей. Очереди будут обрабатываться приложением Java, либо запущенным на сервере приложений, либо автономно, как его собственная служба.
2) Используйте решение JMS на основе базы данных для реализации очередей.
Я не очень знаком с JMS, но из того, что я прочитал, в данном случае кажется, что это лучшее решение. Основное требование состоит в том, чтобы данные датчика никогда не терялись или не удалялись из очереди перед обработкой, и чтобы они обрабатывались более или менее последовательно. Мы также хотели бы упростить остановку обработки некоторых очередей в определенное время, но при этом они должны накапливать данные, и для этих сообщений никогда не истечет автоматически.
При использовании стратегии 1 для меня очевидно, как выполнить эти требования, но она может быть менее надежной и масштабируемой и более сложной для разработки, чем стратегия 2, поскольку мне нужно написать собственный многопоточный код для обработки различных независимые очереди. Мне интересно, какие потенциальные подводные камни могут быть при использовании очередей JMS для этой цели, поскольку я никогда не работал с ними раньше.
Целостность данных - это большая проблема, поэтому мне нужно убедиться, что JMS не сможет гарантировать потерю данных в случае перезагрузки сервера, отключения питания или если по какой-либо причине очередь становится очень большой. Например, может ли проблема завершения транзакций с основной базой данных в течение определенного периода времени привести к нехватке памяти JVM, сбоям и потере всех накопленных данных? (Это будет кошмарный сценарий).
Кроме того, мне было интересно, будет ли какой-либо способ приостановить обработку очереди JMS с помощью инструмента администратора сервера приложений или легко увидеть, что находится в очереди (я бы поставил в очередь объект, который представлял собой сообщение xml плюс какой-то другой данные, включая полученную метку времени и т. д.) Я прочитал несколько постов, посвященных связанным с этим вопросам, но хотел получить прямой отклик. В основном я хотел бы знать случаи (если таковые имеются), где JMS не является подходящим решением для очередей, и если это один из таких случаев. Любой совет с благодарностью.