A quoi sert ActiveMQ?
Je l'ai cherché et vous lui avez envoyé des messages. Mais pourquoi? Pourquoi ne pas simplement utiliser une base de données? ActiveMQ doit avoir une fonctionnalité que les bases de données n’ont pas?
Il est utilisé pour communiquer de manière fiable entre deux processus distribués. Oui, vous pouvez stocker des messages dans une base de données pour communiquer entre deux processus, mais dès que le message est reçu, vous devez le supprimer. Cela signifie une ligne insérer et supprimer pour chaque message. Lorsque vous essayez d'intensifier la communication de milliers de messages par seconde, les bases de données ont tendance à tomber.
Le middleware orienté message, comme ActiveMQ, est conçu pour gérer ces cas d'utilisation. Ils supposent que les messages d'un système sain seront supprimés très rapidement et peuvent procéder à des optimisations pour éviter la surcharge. Il peut également envoyer des messages aux consommateurs au lieu qu'un consommateur ait à rechercher un nouveau message en effectuant une requête SQL. Cela réduit davantage la latence impliquée dans le traitement des nouveaux messages envoyés au système.
ActiveMQ, ou en général toutes les implémentations MOM (Message Oriented Middleware) sont conçues dans le but d’envoyer des messages entre deux applications, ou deux composants dans une application.
MOM et les bases de données partagent une base commune en ce sens qu’elles fournissent un stockage de données transactionnel et persistant permettant de lire et d’écrire. La grande différence réside dans le modèle d'utilisation - les bases de données étant très génériques et optimisées pour la recherche complexe sur plusieurs tables, les MOM sont optimisés pour la lecture de messages, l'un après l'autre, à la manière FIFO.
JMS, qui est une API implémentée par API, est une pierre angulaire importante dans les applications d'entreprise Java. Cela permet aux messages de partager un format et une sémantique assez communs, ce qui facilite l'intégration entre différentes applications.
Bien sûr, de nombreuses fonctionnalités plus détaillées ne sont disponibles que dans ActiveMQ, des protocoles filaires tels que OpenWire, STOMP et MQTT, JMS, EIP et Apache Camel, des modèles de message tels que "demande/réponse" et "publier/souscrire", JMS. Bridging, clustering ("réseau de courtiers"), qui permettent la mise à l'échelle, les distributions, etc.
Active MQ offre une excellente prise en charge du planificateur, ce qui signifie que vous pouvez planifier la livraison de votre message à une heure donnée. Nous avons utilisé cette fonctionnalité pour envoyer des rappels de médicaments au patient en téléchargeant les détails de ses médicaments dans un scénario de soins de santé.
Avec le SGBDR, lorsque vous traitez une ligne de données, vous mettez généralement à jour un indicateur indiquant que la ligne a été traitée de sorte que le traitement ne soit pas répété.
Toutefois, avec Message Queue, il vous suffit d'acquitter un message et le prochain consommateur traitera le suivant.
La différence est que l'état UPDATE dans un SGBDR est une opération très lente comparée à l'état acknowlege dans activmeq.
je voudrais souligner les points suivants:
découplé: les systèmes peuvent communiquer sans être connectés. La file d'attente se situe entre les systèmes, une panne système n'affectera jamais les autres, car la communication se fait par la file d'attente. Les systèmes continuent de fonctionner quand ils sont en place.
support de récupération: les messages dans les files d'attente ont persisté. Les messages peuvent être restaurés ultérieurement si la file d'attente échoue.
Communication fiable: Considérons un système qui traite les demandes du client. Dans des cas normaux, le système reçoit 100 demandes par minute. Ce système n'est pas fiable lorsque le nombre de demandes dépasse la moyenne. Dans ce cas, Queue peut gérer les demandes et transmettre des messages périodiquement en fonction du débit du système sans le casser.
Asynchrone: la communication client serveur est non bloquante. Une fois que le client a envoyé une demande au serveur, il peut effectuer d'autres opérations sans attendre de réponse. Lorsque la réponse est reçue, le client peut le gérer à tout moment.
De Wikipedia
Apache ActiveMQ est un courtier de messages open source écrit en Java avec un client complet Java Message Service (JMS). Il fournit des "fonctionnalités d'entreprise" qui cas signifie encourager la communication de plus d'un client ou serveur
En ce qui concerne vos questions:
Pourquoi ne pas utiliser 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 deviez envoyer un message de l'expéditeur au destinataire. À la réception du message, le destinataire exécute une opération (recevoir, traiter et oublier). Après avoir traité ce message, vous n'en avez plus besoin. Dans ce cas, stocker le message dans une base de données persistante n'est pas une bonne solution.
Je suis entièrement d'accord avec @ Hiram Chirino pour ce qui est de l'insertion et de la suppression d'un message dans la base de données si vous utilisez une base de données au lieu d'un système de messagerie.
Avantages de ceci article et ceci article
- Intégration d'entreprise : permet aux applications construites avec différentes langues et sur différents systèmes d'exploitation 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.
- Communication fiable - les producteurs/consommateurs de messages ne doivent pas nécessairement être disponibles en même temps
- Mise à l'échelle - peut être mise à l'échelle horizontalement en ajoutant plus de services
- Communication asynchrone - un client peut envoyer un message et poursuivre un autre traitement au lieu de le bloquer jusqu'à ce que le service ait envoyé une réponse.
- Couplage réduit - les hypothèses retenues par les clients et les services sont considérablement réduites du fait des 5 avantages précédents. Un service peut modifier des détails sur lui-même, y compris son emplacement, son protocole et sa disponibilité, sans affecter ou perturber le client.
Il doit y avoir une fonctionnalité ActiveMQ a que les bases de données ne sont pas?
Il y a beaucoup de. Consultez la page documentation pour plus de détails. Regardez se-cases aussi.
Jetez un œil à ceci présentation pour comprendre les éléments internes d’ActiveMQ.
Supposons que vous ayez une application utilisée à plusieurs endroits en même temps. Supposons également que votre application doit gérer 1 000 requêtes par minute ou quelque chose du genre, de sorte que les opérations de base de données normales ne peuvent pas gérer de telles opérations. Activemq agit comme le traitement du message. Il met tous les messages en file d'attente. l'autre endroit ne sera pas affecté.