Lecture de la documentation ActivemQ (nous utilisons la version 5.3), je trouve une section sur la possibilité d'utiliser un adaptateur de persistance JDBC avec ActiveMQ.
Quels sont les avantages? Fournit-il un gain de performance ou de fiabilité? Quand devrais-je l'utiliser?
3 Réponses :
À mon avis, vous utiliseriez la persistance JDBC si vous souhaitiez avoir un courtier de basculement et vous ne pouviez pas utiliser le système de fichiers. La persistance JDBC était significativement plus lente (lors de nos tests) que de journaliser dans le système de fichiers. Pour un seul courtier, le système de fichiers journalé est le meilleur.
Si vous exécutez deux courtiers dans un basculement actif / passif, les deux courtiers doivent avoir accès au même journal / magasin de données afin que le courtier passif puisse détecter et prendre la relève si le principal échoue. Si vous utilisez le système de fichiers journalé, les fichiers doivent figurer sur un lecteur réseau partagé d'une sorte, à l'aide de NFS, de WinShare, de ISCSI, etc. Cela nécessite généralement un périphérique NAS plus haut de gamme si vous souhaitez éliminer le partage de fichiers. un seul point d'échec.
L'autre option est que vous pouvez signaler les deux courtiers à la base de données, que la plupart des applications ont déjà accès à. Le compromis est généralement de simplicité au prix de la performance, car la persistance JDBC journalisée était plus lente dans nos tests.
Nous exécutons ActiveMQ dans une paire de courtiers active / passive avec une persistance journalisée via une monture NFS à un périphérique NAS dédié, et cela fonctionne très bien pour nous. Nous sommes en mesure de traiter plus de 600 msgs / sec par le biais de notre système sans problème.
Yeap, c'était exactement mon expérience. Dans nos tests, la persistance JDBC était plusieurs fois plus lente que l'option de journalisation. Merci
Hey, l'utilisation de JDBC journalisé semble être meilleure que d'utiliser la persistance JDBC que depuis que la journalisation est très plus rapide que la persistance JDBC. Il vaut mieux que la persistance de Juste Justenalled Seulement Cos 'Vous avez une sauvegarde supplémentaire des messages de la DB. Journald JDBC a l'avantage supplémentaire que les mêmes données de journaliennes sont persistées à la DB plus tard et que cela peut être consulté par les développeurs en cas de besoin!
Toutefois, lorsque vous utilisez la topologie MASTER / SLAVE activemq avec JDBC JOURNALLÉE, vous risquez de perdre des messages car vous pourriez avoir des messages dans une journal qui ne sont pas encore entrés dans la DB!
Si vous avez une stratégie de plug-in Redelivery en place et utilisez une configuration maître / esclave, le planificateur est utilisé pour la livraison.
À compter d'aujourd'hui, le planificateur ne peut être configuré que sur une base de données de fichiers et non sur le JDBC. Si vous ne faites pas attention à cela, vous allez prendre tous les messages qui se trouvent dans la remontée du scénario HA et local au courtier.
https://issues.apache.org/jira/browse/amq-5238 est un problème dans Apache Issue Tracker qui demande un adaptateur de persistance JDBC pour SchedulerDB. Vous pouvez faire un vote pour que cela se produise.
En réalité, même sur la solution AMQ HA TOP, LEVELDB + ZOOOKEEPER, le planificateur est sorti du jeu et documenté pour créer des problèmes ( http://activemq.apache.org/repliquée-leveldb-store.html à la fin de la page).
Dans un scénario JDBC, il peut être considéré comme dangereux et non pris en charge, mais du moins pas clairement documenté, comment configurer le magasin de données pour la stratégie de rétablissement.