Je pense que beaucoup d'applications (printemps dans mes cas) à l'aide de JMS peuvent suivre ce flux de travail:
Database A ===> Producer ===> JMS Queue ===> Consumer ===> Database B
3 Réponses :
1) de mon expérience avec les gestionnaires de file d'attente (série MQ, ActiveMQ et HornetQ) Je n'ai jamais eu besoin de ce type de reconnaissance entre producteur / consommateur. De plus, l'environnement que j'ai utilisé pour faire face, le trafic était d'environ 50/60 millions par jour d'objets sur plusieurs files d'attente. Et les files d'attente sont également persistées.
2) Dans mon cas, l'utilisation du mécanisme de persistance sur la file d'attente était totalement suffisante pour gérer un scénario d'électricité. J'ai utilisé la persistance du disque sur la série MQ et Hornetq.
Cependant, parfois à ACK, la quantité de messages, nous avons développé certains mécanismes pour comparer la base de données A avec la base de données B, pour être sûr que les messages ont également été consommés. Je ne sais pas si l'architecture JMS devrait fournir ce type de mécanisme, car une telle tâche pourrait diminuer la performance.
C'est quelque chose - à mon point de vue - que vous devez mesurer sur votre architecture système à quel point il est important de faire correspondre ces informations, car ce n'est pas si facile à conserver.
Cordialement.
Merci. Donc, je suppose que la tolérance blackout est fournie par les serveurs d'applications (WebSphere, Weblogic, JBoss ...), que diriez-vous de l'activemq afin que l'application puisse être fiable par elle-même?
Je pense que vous pouvez vérifier sur Activemq Docs, sur la section de persistance ( Activemq.apache.org/persistence.htmlle a>). Depuis la version 4.1, vous pouvez configurer la fonctionnalité de persistance à l'aide de disque ou de base de données. Je n'ai jamais utilisé sur ce gestionnaire de files d'attente, mais je sais que c'est possible. :)
Merci pour votre réponse rapide. Je dois garder la question ouverte pendant un moment pour inviter plus d'opinions, mais votre idée est précieuse :)
Aucun problème du tout. Je suis content d'aider. Salutations.
Si je comprends votre question, cela semble être un cas pour les transactions JTA / XA (tant que vos fournisseurs de DB / JMS les soutiennent). Les gestionnaires de Spring TX peuvent vous aider à faire de la gestion TX (plus) fournisseur agnostique.
FYI, j'utilise Apache Camel pour ce type de débit qui a une très bonne manipulation d'erreurs à travers les producteurs / consommateurs.
JTA signifie API de transaction Java, il s'agit simplement d'une JSR sur la gestion des transactions dans Java et le support des fournisseurs de RDBMS / MQ ne sont pas pertinents. Je suppose que vous vouliez dire XA (transaction distribuée de plusieurs ressources) Notez que JMS est également une JMS EE JSR et que toute mise en œuvre est donc conforme à XA (sinon, ils ne fournissent pas de mise en œuvre JMS, mais une simple messagerie simple)
De plus, la transaction n'est jamais distribuée sur des limites de maman (producteur et consommateur) car elle est conflictuelle avec la nature asynchrone de la messagerie des mamans. La production d'un message peut être transactionnelle et consommer également, mais elles ne feront jamais partie de la même transaction.
Oui, JTA / XA, merci. Je pense que nous avons différentes définitions de maman. Certains (comme ActiveMQ) implémentent l'API JMS et prennent en charge les transactions XA, mais certaines (comme la rabbbitmq) ne mettent pas en œuvre l'API JMS et ne prennent pas en charge les transactions globales. Bien sûr, beaucoup de conducteurs DBS (et DB) ne soutiennent pas XA. Mon point était qu'une transaction globale devrait être en mesure de laisser le producteur savoir que le consommateur était / n'a pas réussi (et que le gestionnaire Spring TX peut aider).
JMS garantit la livraison du message par nature, si le message est affiché, il sera livré à un consommateur s'il y en a un, tout ce qui se produit, la mère est conçue pour assurer ce fait. Quoi qu'il en soit, livré ne signifie pas nécessairement traité.
La fiabilité est assurée par divers mécanismes:
Pour assurer la cohérence entre les deux datasources que vous devez utiliser une transaction XA au moins du côté du producteur (vous avez au moins 2 ressources impliquées dans la base de données de transaction A et JMS Wee) afin de garantir que le message ne sera pas Publié dans la file d'attente si la base de données de base de données échoue ou la base de données ne sera pas mise à jour si le poste sur la file d'attente échoue. La consommation de message doit également être transaction pour assurer la rétablissement en cas de restauration.
Les limites des transactions n'incluront jamais les consommateurs et le producteur, car il est en conflit avec la nature asynchrone du système de messagerie, vous ne pouvez pas vous permettre de verrouiller les ressources du côté du producteur tant que le processus de consommateur est le message, car vous n'avez aucune garantie sur quand cela arrivera.
NB: Dans le cas où votre base de données ne prend pas en charge XA (ou pour améliorer les performances) et si vous n'avez que 2 ressources impliquées dans la transaction (base de données et la file d'attente JMS), vous pouvez consulter Organisation de l'optimisation des transactions de la ressource