Я пытаюсь создать надежную среду JMS с помощью ActiveMQ. Я планирую использовать подход кластеризации JDBC master-slave, в котором я могу сохранять сообщения, полученные главным сервером, в базу данных, а подчиненный сервер может выбирать эти сообщения и запускать их в случае, если главный сервер умирает. Но у меня нет решения ситуации, когда и ведущий, и ведомый выходят из строя (по любой причине). Если это произойдет, не исчезнут ли сообщения, отправленные производителем, навсегда? Я могу делать что-то вроде сохранения сообщений в базе данных и их выполнения после восстановления одного из серверов JMS, но есть ли лучшее / встроенное решение для обработки таких сценариев?
Надежность JMS, обработка сбоя сервера
Ответы (1)
Я могу делать что-то вроде сохранения сообщений в базе данных и их выполнения после восстановления одного из серверов JMS, но есть ли лучшее / встроенное решение для обработки таких сценариев?
Вы правильно поняли. Если производитель не может подключиться при нормальных обстоятельствах, он вызовет исключение. Вам нужен продюсер с запасом хода (SAF); если клиент не может достичь места назначения, сообщения хранятся локально в файловой системе клиента и отправляются, когда клиент повторно подключается к брокеру.
Судя по приведенным ниже комментариям, ActiveMq поддерживает с промежуточным хранением с использованием локального хранилища для клиентов. Я просил никого не отправлять его комментарии в качестве ответа.
person
raffian
schedule
07.12.2013
Обратите внимание, что с помощью activemq вы также можете встроить брокера в клиентское приложение и передать его реальному брокеру, по сути, предоставив вам SAF на клиенте.
- person nos; 07.12.2013
@nos Интересно, не знал что! Является ли встраиваемый брокер таким же тяжеловесным процессом, как и брокер на стороне сервера? Если встраивание брокера потребляет ресурсы у клиента, оно контрпродуктивно; в противном случае это решение, 100%.
- person raffian; 07.12.2013
Это тот же код, хотя обычно вы не активируете все функции / модули. Это не тяжелый вес, встраивание activemq даже часто используется только для межпоточного взаимодействия (с транспортом vm: //)
- person nos; 07.12.2013
Так это тоже фреймворк параллелизма? Очень круто! Я кое-что узнал сегодня! Я собирался обновить свой ответ, но из уважения я удалю его, если вы хотите вместо этого опубликовать свой ответ ;-) Дайте мне знать
- person raffian; 07.12.2013
Действительно здорово, что у activemq есть такая функция, но она все еще не решает мою проблему с обработкой ситуации, когда все серверы JMS выходят из строя. Я слишком осторожен? Если нет, то является ли сохранение в базе данных самым безопасным вариантом, который у меня есть? Я пытаюсь быть более зависимым от базы данных, потому что все мое приложение выйдет из строя в случае сбоя базы данных, поэтому нет никаких шансов на пропущенные сообщения. Пожалуйста, примите во внимание ..
- person Adithya Puram; 09.12.2013
Брокеры могут быть настроены для сохранения сообщений в базе данных, и это работает для брокеров на сервере и тех, которые встроены в клиенты. Кроме того, я не уверен, что вас беспокоит. В JMS всегда есть крайние случаи, когда сообщения могут отбрасываться, и некоторые поставщики лучше других избегают таких случаев, и, конечно же, лучше всего являются коммерческие продукты.
- person raffian; 09.12.2013
