À quoi sert ActiveMQ - pouvons-nous appliquer le concept de messagerie à l'aide d'une base de données?
116
Je l'ai recherché et il envoyait des messages entre 2 systèmes.
Mais pourquoi? Pourquoi n'utiliseriez-vous pas simplement un Database?
Il doit y avoir une fonctionnalité qui ActiveMQn'a Databasespas?
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 devrez DELETEle message, cela signifie une ligne INSERTet DELETEpour chaque message.
Lorsque vous essayez de l' échelle que jusqu'à la communication des milliers de messages par seconde, les bases de données ont tendance à tomber .
Le middleware orienté message [MOM] comme ActiveMQd'autre part est construit pour gérer ces cas d'utilisation.
Ils supposent que les messages dans un système sain seront supprimés très rapidement et peuvent effectuer des optimisations pour éviter la surcharge .
Il peut également envoyer des messages aux consommateurs au lieu de devoir interroger le nouveau message en effectuant une requête SQL.
Cela réduit encore la latence impliquée dans le traitement des nouveaux messages envoyés dans le système.
Belle explication! Les deux processus distribués doivent-ils appartenir au même processus? Je veux dire deux instances de la même application?
Maverick
Non, les applications arbitraires peuvent communiquer entre elles via ActiveMQ. Par exemple, les applications A et B pourraient créer des files d'attente AB et BA (lire: messages pour A à partir de B et inversement) et s'envoyer des messages l'une pour l'autre vers la file d'attente correspondante.
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.
Essentiellement, MOM et les bases de données partagent une base commune en ce sens qu'ils fournissent un stockage de données transactionnel et persistant pour la lecture et l'écriture.
La grande différence est le modèle d'utilisation - où 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 lire les messages, un à la fois, dans un mode FIFO [Queue].
JMS, qui est une API implémentée par ActiveMQ, est une pierre angulaire importante des applications Java Enterprise. Cela permet aux messages de partager un format et une sémantique plutôt communs, ce qui facilite l'intégration entre différentes applications.
Bien sûr, il y a beaucoup de caractéristiques plus détaillées qui sont seulement dans ActiveMQ, les protocoles de fil comme OpenWire, STOMPet MQTT, JMS, EIPavec Apache Camel, les modèles de message comme « demande / réponse » et « publication / abonnement », JMS Bridging, le regroupement ( » réseau de courtiers "), qui permettent à l' échelle et la distribution, etc.
vous devriez lire sur ces sujets un peu si vous êtes intéressé , car ils sont assez grandes.
ActiveMQa une excellente prise en charge des planificateurs , ce qui signifie que vous pouvez planifier l'envoi de votre message à un moment donné .
Nous avons utilisé cette fonctionnalité 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é.
C'est plutôt cool. Nous avons utilisé la bibliothèque de planification Quartz à des fins de rappel similaires.
Siddhartha
Nous avons utilisé la base Scheduled Jobsde données Oracle aux mêmes fins.
ahmednabil88
15
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 afin que le traitement ne soit pas répété.
Cependant, avec Message Queue, vous n'avez qu'à accuser réception d'un message et le prochain consommateur traitera le suivant.
La différence est que l' UPDATEinstruction dans un SGBDR est une opération très lente par rapport à acknowledgein activmeq.
Découplé : les systèmes peuvent communiquer sans être connectés. La file d'attente se situe entre les systèmes, une défaillance du système n'affectera jamais les autres car la communication se fait via la file d'attente. Les systèmes continuent de fonctionner lorsqu'ils sont en place.
Prise en charge de la récupération : les messages dans les files d'attente ont persisté. Les messages peuvent être restaurés plus tard si la file d'attente échoue.
Communication fiable : envisagez un système qui traite les demandes des clients. Dans des cas normaux, le système reçoit 100 requêtes par minute. Ce système n'est pas fiable lorsque le nombre de requêtes dépasse la moyenne. Dans ce cas, Queue peut gérer les demandes et envoyer des messages périodiquement en fonction du débit du système sans le casser.
Asynchrone : la communication client-serveur n'est pas bloquante. Une fois que le client a envoyé la demande au serveur, il peut effectuer d'autres opérations sans attendre la réponse. Lorsque la réponse qu'il a reçue, le client peut le gérer à tout moment.
Apache ActiveMQ est un courtier de messages open source écrit en Java avec un client Java Message Service (JMS) complet. Il fournit des «fonctionnalités d'entreprise» qui, dans ce cas, signifie favoriser la communication à partir de plusieurs clients ou serveurs
Concernant vos requêtes:
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. À la réception du message, le récepteur exécute une opération (réception, traitement et oubli). Après avoir traité ce message, vous n'avez pas du tout besoin de ce message. 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 la réponse de @Hiram Chirino concernant l'insertion et la suppression d'un message dans la base de données si vous utilisez la base de données au lieu du système de messagerie.
Intégration d'entreprise : permettre aux applications créées 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 n'ont pas besoin d'être disponibles en même temps
Mise à l'échelle - peut évoluer horizontalement en ajoutant plus de services
Communication asynchrone - un client peut déclencher un message et continuer un autre traitement 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 considérablement réduites en raison des 5 avantages précédents. Un service peut modifier les détails le concernant, y compris son emplacement, son protocole et sa disponibilité, sans affecter ni perturber le client.
Il doit y avoir une fonctionnalité ActiveMQ que les bases de données n'ont pas?
Il y a beaucoup de. Consultez la page de documentation pour plus de détails. Jetez également un œil aux cas d'utilisation .
Jetez un œil à cette présentation pour comprendre les éléments internes d'ActiveMQ.
Supposons que vous ayez une application qui est utilisée à plusieurs endroits en même temps. Supposons également que votre application doive gérer des milliers de requêtes par minute ou quelque chose du genre afin que les opérations de base de données normales ne puissent pas gérer de telles opérations, Activemq agit comme le traitement des messages, il prend tous les messages dans la file d'attente, donc même si l'une de vos applications se bloque à un endroit l'autre emplacement ne sera pas affecté.
Réponses:
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 devrez
DELETEle message, cela signifie une ligneINSERTetDELETEpour chaque message.Lorsque vous essayez de l' échelle que jusqu'à la communication des milliers de messages par seconde, les bases de données ont tendance à tomber .
Le middleware orienté message [MOM] comme
ActiveMQd'autre part est construit pour gérer ces cas d'utilisation.Ils supposent que les messages dans un système sain seront supprimés très rapidement et peuvent effectuer des optimisations pour éviter la surcharge .
Il peut également envoyer des messages aux consommateurs au lieu de devoir interroger le nouveau message en effectuant une requête SQL.
Cela réduit encore la latence impliquée dans le traitement des nouveaux messages envoyés dans le système.
la source
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.Essentiellement, MOM et les bases de données partagent une base commune en ce sens qu'ils fournissent un stockage de données transactionnel et persistant pour la lecture et l'écriture.
La grande différence est le modèle d'utilisation - où 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 lire les messages, un à la fois, dans un mode FIFO [Queue].
JMS, qui est une API implémentée par ActiveMQ, est une pierre angulaire importante des applications Java Enterprise. Cela permet aux messages de partager un format et une sémantique plutôt communs, ce qui facilite l'intégration entre différentes applications.Bien sûr, il y a beaucoup de caractéristiques plus détaillées qui sont seulement dans ActiveMQ, les protocoles de fil comme
OpenWire,STOMPetMQTT,JMS,EIPavec Apache Camel, les modèles de message comme « demande / réponse » et « publication / abonnement », JMS Bridging, le regroupement ( » réseau de courtiers "), qui permettent à l' échelle et la distribution, etc.vous devriez lire sur ces sujets un peu si vous êtes intéressé , car ils sont assez grandes.
la source
ActiveMQa une excellente prise en charge des planificateurs , ce qui signifie que vous pouvez planifier l'envoi de votre message à un moment donné .Nous avons utilisé cette fonctionnalité 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é.
la source
Scheduled Jobsde données Oracle aux mêmes fins.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 afin que le traitement ne soit pas répété.
Cependant, avec Message Queue, vous n'avez qu'à accuser réception d'un message et le prochain consommateur traitera le suivant.
La différence est que l'
UPDATEinstruction dans un SGBDR est une opération très lente par rapport àacknowledgein activmeq.la source
je voudrais souligner ce qui suit:
Découplé : les systèmes peuvent communiquer sans être connectés. La file d'attente se situe entre les systèmes, une défaillance du système n'affectera jamais les autres car la communication se fait via la file d'attente. Les systèmes continuent de fonctionner lorsqu'ils sont en place.
Prise en charge de la récupération : les messages dans les files d'attente ont persisté. Les messages peuvent être restaurés plus tard si la file d'attente échoue.
Communication fiable : envisagez un système qui traite les demandes des clients. Dans des cas normaux, le système reçoit 100 requêtes par minute. Ce système n'est pas fiable lorsque le nombre de requêtes dépasse la moyenne. Dans ce cas, Queue peut gérer les demandes et envoyer des messages périodiquement en fonction du débit du système sans le casser.
Asynchrone : la communication client-serveur n'est pas bloquante. Une fois que le client a envoyé la demande au serveur, il peut effectuer d'autres opérations sans attendre la réponse. Lorsque la réponse qu'il a reçue, le client peut le gérer à tout moment.
la source
De Wikipedia
Concernant vos requêtes:
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. À la réception du message, le récepteur exécute une opération (réception, traitement et oubli). Après avoir traité ce message, vous n'avez pas du tout besoin de ce message. 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 la réponse de @Hiram Chirino concernant l'insertion et la suppression d'un message dans la base de données si vous utilisez la base de données au lieu du système de messagerie.
Bénéficie de cet article et de cet article
Il y a beaucoup de. Consultez la page de documentation pour plus de détails. Jetez également un œil aux cas d'utilisation .
Jetez un œil à cette présentation pour comprendre les éléments internes d'ActiveMQ.
la source
Supposons que vous ayez une application qui est utilisée à plusieurs endroits en même temps. Supposons également que votre application doive gérer des milliers de requêtes par minute ou quelque chose du genre afin que les opérations de base de données normales ne puissent pas gérer de telles opérations, Activemq agit comme le traitement des messages, il prend tous les messages dans la file d'attente, donc même si l'une de vos applications se bloque à un endroit l'autre emplacement ne sera pas affecté.
la source