Beim Lesen der ActiveMQ-Dokumentation (wir verwenden die Version 5.3) finde ich einen Abschnitt über die Möglichkeit, einen JDBC-Persistenzadapter mit ActiveMQ zu verwenden.Wann sollte ich den JDBC Persistence Adapter in ActiveMQ verwenden?
Was sind die Vorteile? Bietet es irgendeinen Gewinn an Leistung oder Zuverlässigkeit? Wann sollte ich es benutzen?
Meiner Meinung nach würden Sie JDBC-Persistenz verwenden, wenn Sie einen Failover-Broker haben wollten und Sie das Dateisystem nicht verwenden konnten. Die JDBC-Persistenz war signifikant langsamer (während unserer Tests) als das Journaling für das Dateisystem. Für einen einzelnen Broker ist das aufgezeichnete Dateisystem am besten.
Wenn Sie zwei Broker in einem aktiven/passiven Failover ausführen, müssen die beiden Broker Zugriff auf denselben Journal/Datenspeicher haben, damit der passive Broker erkennen und übernehmen kann, wenn der primäre Fehler auftritt. Wenn Sie das Journaled File System verwenden, müssen sich die Dateien auf einem freigegebenen Netzwerklaufwerk befinden, unter Verwendung von NFS, WinShare, iSCSI usw. Dies erfordert normalerweise ein High-End-NAS-Gerät, wenn Sie die Dateifreigabe als entfernen möchten ein einzelner Fehlerpunkt.
Die andere Option ist, dass Sie beide Broker auf die Datenbank verweisen können, auf die die meisten Anwendungen bereits Zugriff haben. Der Kompromiss ist in der Regel die Einfachheit zum Preis der Leistung, da die JDBC-Fortdauer in unseren Tests langsamer war.
Wir betreiben ActiveMQ in einem aktiven/passiven Broker-Paar mit Journaled Persistence über eine NFS-Mount auf einem dedizierten NAS-Gerät, und es funktioniert sehr gut für uns. Wir sind in der Lage, über 600 msg/s ohne Probleme durch unser System zu verarbeiten.
Hey, die Verwendung von Journaled JDBC scheint besser zu sein als die Verwendung von JDBC Persistenz nur, da das Journaling ist sehr viel schneller als JDBC Persistenz. Es ist besser als nur Journaled Persistence nur cos 'Sie haben eine zusätzliche Sicherung der Nachrichten in der Datenbank. Journaled JDBC hat den zusätzlichen Vorteil, dass die gleichen Daten im Journal später in der Datenbank gespeichert werden und auf diese bei Bedarf von Entwicklern zugegriffen werden kann!
Wenn Sie jedoch Master/Slave-ActiveMQ-Topologie mit Journaled JDBC verwenden, können Sie möglicherweise Nachrichten verlieren, da Sie möglicherweise Nachrichten im Journal haben, die noch nicht in der DB sind!
Wenn Sie eine Rücklieferungs-Plug-in-Richtlinie installiert haben und ein Master/Slave-Setup verwenden, wird der Scheduler für die erneute Zustellung verwendet.
Ab sofort kann der Scheduler nur in einer Dateidatenbank und nicht auf der JDBC eingerichtet werden. Wenn Sie das nicht beachten, werden Sie alle Nachrichten, die sich in der Neuzustellung befinden, aus dem HA-Szenario und lokal für den Broker entfernen.
https://issues.apache.org/jira/browse/AMQ-5238 ist ein Problem im Apache Issue Tracker, das nach einem JDBC-Persistenzadapter für schedulerdb fragt. Sie können eine Stimme dafür abgeben, um es zu ermöglichen.
Eigentlich sogar auf der oberen AMQ HA-Lösung, LevelDB + ZooKeeper, ist der Scheduler aus dem Spiel genommen und dokumentiert, um Probleme zu erstellen (am Ende der Seite).
In einem JDBC-Szenario kann es daher als unsicher und nicht unterstützt, aber zumindest nicht eindeutig dokumentiert angesehen werden, wie der Datenspeicher für die Richtlinie zur erneuten Zustellung eingerichtet wird.
Yeap, das war genau meine Erfahrung. In unseren Tests war die JDBC-Persistenz viel langsamer als die Journaling-Option. Danke –