Чтение документации ActiveMQ (мы используем выпуск 5.3), я нахожу раздел о возможности использования адаптера персистентности JDBC с ActiveMQ.
Каковы преимущества? Обеспечивает ли он прирост производительности или надежности? Когда я должен использовать его?
На мой взгляд, вы бы использовали сохранение JDBC, если вы хотели иметь брокера с откатом, и вы не могли использовать файловую систему. Настойчивость JDBC была значительно медленнее (во время наших тестов), чем ведение журнала в файловой системе. Для одного брокера наилучшая журналированная файловая система.
Если вы запускаете двух брокеров в режиме активного/пассивного перехода на другой ресурс, два брокера должны иметь доступ к тому же журналу/хранилищу данных, чтобы пассивный брокер мог обнаруживать и принимать на себя, если первичный сбой. Если вы используете журналированную файловую систему, то файлы должны быть на общем сетевом диске какого-то типа, используя NFS, WinShare, iSCSI и т.д. Обычно требуется более высокоуровневое NAS-устройство, если вы хотите исключить общий ресурс файла как одна точка отказа.
Другой вариант заключается в том, что вы можете указать оба брокера в базу данных, к которой большинство приложений уже имеют доступ. Компромисс, как правило, является простотой по цене исполнения, поскольку сохраняемость журнала JDBC в наших тестах была медленнее.
Мы запускаем ActiveMQ в активной/пассивной паре брокеров с сохранением журнала с помощью монтирования NFS на специализированное устройство NAS, и это работает очень хорошо для нас. Мы можем обрабатывать более 600 msgs/sec через нашу систему без проблем.
Эй, использование журнала JDBC, похоже, лучше, чем использование JDBC-стойкости только с тех пор, как ведение журнала происходит намного быстрее, чем настойчивость JDBC. Это лучше, чем просто фиксированное сохранение только потому, что у вас есть дополнительная резервная копия сообщений в db. Journeded JDBC имеет дополнительное преимущество в том, что те же данные в журнале сохраняются в db позже, и это может быть доступно разработчиками при необходимости!
Однако, когда вы используете топологию ActiveMQ с master/slave с JDBC с журналом, вы можете потерять сообщения, так как у вас могут быть сообщения в журнале, которые еще не вошли в базу данных!
Если у вас есть политика плагина переопределения на месте и используйте настройку ведущий/ведомый, планировщик используется для повторной доставки.
На сегодняшний день планировщик может быть настроен только в базе данных файлов, а не на JDBC. Если вы не обратили на это внимание, вы будете принимать все сообщения, которые находятся в redelivery из сценария HA и локально для брокера.
https://issues.apache.org/jira/browse/AMQ-5238 является проблемой в трекер-проблеме Apache, которая запрашивает адаптер сохранения JDBC для schedulerdb. Вы можете сделать так, чтобы это произошло.
На самом деле, даже в верхнем решении AMQ HA, LevelDB + ZooKeeper, планировщик выводится из игры и документируется для создания проблем (http://activemq.apache.org/replicated-leveldb-store.html в конце страницы).
В сценарии JDBC, поэтому он может считаться небезопасным и неподдерживаемым, но, по крайней мере, неясно документированным, как настроить хранилище данных для политики переопределения.