J'ai fait des recherches et ça servait à envoyer des messages entre 2 systèmes.
Mais pourquoi ? Pourquoi n'utiliseriez-vous pas simplement un Database
?
Il doit y avoir une fonction qui ActiveMQ
a que Databases
ne le font pas ?
Réponses
Trop de publicités?Il est utilisé pour communiquer de manière fiable entre deux processus distribués.
Oui, vous pouvez stocker des messages dans un Base de données pour communiquer entre deux processus, mais, dès que le message est reçu, vous devrez DELETE
le message, Cela signifie qu'une rangée INSERT
et DELETE
pour chaque message.
Quand vous essayez de échelle qui communiquent des milliers de messages par seconde, Les bases de données ont tendance à tomber .
Les intergiciels orientés message [MOM] comme ActiveMQ
d'autre part, sont construits pour gérer ces cas d'utilisation.
Ils supposent que les messages dans un système sain seront supprimé très rapidement et peut effectuer des optimisations pour éviter les frais généraux .
Il peut également envoyer des messages aux consommateurs sans que ceux-ci aient à demander le nouveau message en effectuant une requête SQL.
Cela réduit encore la latence liée au traitement des nouveaux messages envoyés dans le système.
ActiveMQ
ou, en général, toutes les implémentations de l'intergiciel orienté message (MOM) sont conçues dans le but de l'envoi de messages entre deux applications, ou deux composants dans une seule application.
Essentiellement, le MOM et les bases de données partagent une base commune en ce qu'ils fournissent un stockage de données transactionnel et persistant à partir duquel on peut lire et écrire.
La grande différence réside dans le modèle d'utilisation : alors que les bases de données sont très génériques et optimisées pour des recherches complexes sur plusieurs tables, MOM est optimisé pour la lecture de messages, un par un, à la manière d'un FIFO [Queue].
JMS
Les messages, qui sont une API mise en œuvre par ActiveMQ, sont une pierre angulaire importante des applications Java Enterprise. Les messages partagent ainsi un format et une sémantique assez communs, ce qui facilite l'intégration entre différentes applications.
Bien sûr, il y a beaucoup de fonctionnalités plus détaillées qui ne sont que dans ActiveMQ, des protocoles filaires comme OpenWire
, STOMP
et MQTT
, JMS
, EIP
avec Apache Camel, des modèles de messages tels que "request/reply" et "publish/subscribe", JMS Bridging, clustering ("network of brokers"), qui permettent la mise à l'échelle et les distributions, etc.
Vous devriez vous documenter un peu sur ces sujets si vous êtes intéressé, car ils sont assez vastes.
ActiveMQ
a une grande planificateur support, ce qui signifie que vous pouvez programmer l'envoi de votre message pour qu'il soit livré à une heure précise .
Nous avons utilisé cette fonction pour envoyer des rappels de médicaments aux patients qui téléchargent les détails de leurs médicaments dans un scénario de soins de santé.
Avec les SGBDR, lorsque vous traitez une ligne de données, vous mettez généralement à jour un drapeau indiquant que la ligne a été traitée afin que le traitement ne soit pas répété.
En revanche, avec Message Queue, il suffit d'accuser réception d'un message pour que le consommateur suivant traite le suivant.
La différence est que le UPDATE
dans un SGBDR est une opération très lente par rapport à l'exécution de l'opération. acknowledge
dans activmeq.
De Wikipedia
Apache ActiveMQ est un courtier en messages open source écrit en Java et doté d'un client JMS (Java Message Service) complet. Il offre des "fonctionnalités d'entreprise", ce qui, dans ce cas, signifie qu'il favorise la communication entre plusieurs clients ou serveurs.
En ce qui concerne vos questions :
Pourquoi n'utiliseriez-vous pas une base de données ?
Vous devez utiliser la base de données pour les données persistantes et non pour les données temporaires. Supposons que vous devez envoyer un message de l'expéditeur au destinataire. A la réception du message, le récepteur exécute une opération (recevoir, traiter et oublier). Après avoir traité ce message, vous n'avez plus besoin de ce message du tout. Dans ce cas, le stockage du message dans une base de données persistante n'est pas une bonne solution.
Je suis entièrement d'accord avec @Hiram Chirino réponse concernant l'insertion et la suppression de messages dans la base de données si vous utilisez la base de données au lieu du système de messagerie.
Les avantages de cette article et ceci article
- Intégration des entreprises : Permettre aux applications construites avec des langages différents et sur des systèmes d'exploitation différents de s'intégrer les unes aux autres.
- Transparence de l'emplacement : Les applications clientes n'ont pas besoin de savoir où se trouvent les applications de service.
- Une communication fiable - les producteurs/consommateurs de messages ne doivent pas nécessairement être disponibles au même moment.
- Mise à l'échelle - peut évoluer horizontalement en ajoutant des services supplémentaires
- Communication asynchrone - un client peut envoyer un message et poursuivre d'autres traitements au lieu de bloquer jusqu'à ce que le service ait envoyé une réponse ;
- Couplage réduit - les hypothèses faites par les clients et les services sont fortement réduites grâce aux 5 avantages précédents. Un service peut modifier les détails le concernant, notamment son emplacement, son protocole et sa disponibilité, sans affecter ou perturber le client.
Il doit y avoir une fonctionnalité d'ActiveMQ que les bases de données n'ont pas ?
Il y en a beaucoup. Jetez un coup d'œil à documentation pour plus de détails. Jetez un coup d'œil à cas d'utilisation aussi.
Jetez un coup d'œil à ceci présentation pour comprendre les mécanismes internes d'ActiveMQ.
- Réponses précédentes
- Plus de réponses