Когда мне следует использовать адаптер персистентности JDBC в ActiveMQ?

Question

Читая документацию ActiveMQ (мы используем версию 5.3), я нахожу раздел о возможности использования адаптера персистентности JDBC с ActiveMQ.

Каковы преимущества? Обеспечивает ли это какой-либо выигрыш в производительности или надежности? Когда я должен использовать это?

Answer 1

По моему мнению, вы будете использовать постоянство JDBC, если хотите иметь отказоустойчивый брокер и не можете использовать файловую систему. Постоянство JDBC было значительно медленнее (во время наших тестов), чем ведение журнала в файловой системе. Для одного брокера лучше всего подходит журнальная файловая система.

Если вы работаете с двумя посредниками при активном / пассивном переключении при сбое, два посредника должны иметь доступ к одному и тому же журналу / хранилищу данных, чтобы пассивный посредник мог обнаруживать и принимать управление в случае сбоя основного. Если вы используете журнализированную файловую систему, то файлы должны быть на каком-то общем сетевом диске с использованием NFS, WinShare, iSCSI и т. Д. Обычно для этого требуется устройство NAS более высокого класса, если вы хотите удалить общий файловый ресурс как одна точка отказа.

Другой вариант заключается в том, что вы можете указать обоих брокеров на базу данных, к которой большинство приложений уже имеют доступ. Компромисс обычно прост в цене производительности, так как сохраняемая в журнале стойкость JDBC в наших тестах была медленнее.

Мы запускаем ActiveMQ в паре активный / пассивный брокер с сохраняемым в журнале постоянством через монтирование NFS на выделенное устройство NAS, и это очень хорошо работает для нас. Мы можем обработать более 600 сообщений в секунду через нашу систему без проблем.

Answer 2

Эй, использование журналируемого JDBC кажется лучше, чем использование персистентности JDBC только потому, что ведение журнала намного быстрее, чем сохранение JDBC. Это лучше, чем просто сохраняемое в журнале постоянство, потому что у вас есть дополнительная резервная копия сообщений в БД. Журналируемый JDBC имеет дополнительное преимущество, заключающееся в том, что те же данные в журнале сохраняются в БД позже, и разработчики могут получить к ним доступ при необходимости!

Однако, когда вы используете топологию Master / Slave ActiveMQ с журналированным JDBC, вы можете в конечном итоге потерять сообщения, поскольку в журнале могут быть сообщения, которых еще нет в БД!

Answer 3

Если у вас есть политика плагинов для повторной доставки, и вы используете настройку master / slave, для повторной доставки используется планировщик.

На сегодняшний день планировщик может быть настроен только для файловой базы данных, но не для JDBC. Если вы не будете обращать на это внимание, вы удалите все сообщения, находящиеся в повторной доставке, из сценария высокой доступности и локальные для брокера.

https://issues.apache.org/jira/browse/AMQ-5238 - это проблема в системе отслеживания ошибок Apache, которая запрашивает адаптер персистентности JDBC для schedulerdb. Вы можете проголосовать за это, чтобы это произошло.

На самом деле, даже в топовом решении AMQ HA LevelDB + ZooKeeper планировщик вынимается из игры и документируется для создания проблем (http://activemq.apache.org/replicated-leveldb-store.html в конце страницы).

В сценарии JDBC его можно считать небезопасным и неподдерживаемым, но, по крайней мере, не совсем задокументированным, как настроить хранилище данных для политики повторной доставки.