Когда мне следует использовать адаптер постоянства 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 с журналированием имеет дополнительное преимущество: те же данные в журнале позже сохраняются в базе данных, и разработчики могут получить к ним доступ при необходимости!

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

Answer 3

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

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

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

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

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