Доброго времени суток. Хотел бы узнать, как на реальных Java проектах решаются следующего рода задачи:
1) Есть API, нужно асинхронно обрабатывать все прилетающие сообщения.
2) Есть набор задач, которые нужно проделывать постоянно, повторяя каждую минуту.
В проекте, в котором я работаю пишем на php. 1 пункт решается с помощью сервера очередей RabbitMQ, очереди которого слушают одновременно кучи косьюмеров, т.е. висят воркера и обрабатывают все это.
Второй пункт решается так же запуском консольных тасок, которые крутятся в бесконечном цикле.
Управление воркерами идет с помощью supervisor, если необходимо добавить скорости, добавляется n инстансов воркера.
Задачи взял просто ради примера, интересует именно концепция решения подобных задач в Java. Проще говоря, как java работают real time приложения, по такому же принципу создаются разные воркера и запускаются по отдельности или как-то иначе. За счет чего увеличивают производительность, это так же кучи инстансов или что-то с потоками связанное? И как делаются вечно работающие приложения, while (true) {...} и вперед или есть более изящные решения?
Денис Загаевский, суть вопроса моего не ясна совсем, правда, вот ну никак, да? Хочешь придираться к каждой букве - валяй, но лучше бы по существу что сказал.
Денис Загаевский, интересно-интересно, что же по вашему реалтайм?! И почему нельзя использовать очереди? А в режиме broarcast можно? А латенси тут роль играет? А какая она для реалтайм нужна? А чем пыхпых плох? Он лучше питона или луа? Или только Си можно? А контроллер с интерпретатором МЭК и 100милисекундным циклом это тру? Или на 10 милисекунд разогнать нужно? А реалтайм по rs-485 гонять можно? Или профибас нужен? А очереди там есть? Или ниже нифинибанда не опускаться? А ничего, что там интерпретатор? Ух ты, он еще и автоматикой газотурбины успевает управлять!?
Это я как разработчик и системный программист со стажем в 15 лет в этом вот реалтайме, написав драйверов и портировав этих вот систем с косой десяток! Блин, как же за#%^## люди, ничего не знающие, но любящие взбзднуть (9 букв и одна гласная, да, слово-фантастика, еще поискать такое).
Тут все зависит от архитектора и архитектуры.
Собственно, все практически тоже самое, берется очередь, и на нее сажаются воркеры.
Сами очереди есть в любом JEE контейнере. Также в любом JEE контейнере можно запустить нужное количество воркеров. Т.е. это вот все уже заложено в саму спецификацию JEE, также есть куча разных реализаций как очередей, так и контейнеров, которые поддерживают единый API взаимодействия. Есть jboss, glassfish и еще добрый десяток реализаций. Это так сказать традиционный путь. Здесь мы получаем единый механизм управления, деплоя и взаимодействия в рамках экосистемы.
Также можно все тоже самое реализовать и в связке с rabbitMQ и просто плодить процессы в качестве воркеров. А можно и из контейнера подцепиться к тому же самому rabbitMQ.
Ну, можно и в рамках томката запустить воркеров, но лучше этого не делать, так как томкат и иже с ним типа jetty - контейнеры сервлетов и нацелены на работу с web.
В этом случае либо используют легковесные фреймворки типа spring, либо просто пишут воркеров типа "do ... while", которые работают как обычные процессы в системе.
Да, при этом никто не запрещает в в web-приложении подключиться к тому же самому rabbitMQ или удаленному JEE, или какй-то левой очереди сообщений. Или использовать акторы https://akka.io иил еще что для передачи сообщений.
Тут единого подхода нет, и наверное не будет. Путей решения любой задачи сотни, благо разных библиотек и фреймворков сделано столько, что иногда главной задачей становится выбор того самого фреймворка, которому вся команда готова положить жизнь года на 2-3 :-)
Простой
