Vous ne savez pas quand vous devez utiliser JMS (ou une file d'attente en général) plutôt qu'une base de données.

Question

Lorsque vous stockez un message dans une file d'attente, ne s'agit-il pas plutôt d'informations de type méta-données, de sorte que la personne qui extrait le message de la file d'attente sache comment traiter les données ? Les informations réelles de la file d'attente ne contiennent pas toujours toutes les informations.

Si vous avez une application comme Twitter, lorsque quelqu'un publie un message, vous devez toujours stocker le texte du message dans la base de données, n'est-ce pas ?

La file d'attente serait plutôt utilisée pour diffuser aux autres abonnés qu'un nouveau message est arrivé, puis ces services pourraient prendre d'autres mesures.

Ou pouvez-vous en fait stocker le texte du tweet dans la file d'attente également ? (ou vous pourriez le faire, mais ce serait stupide ?)

Un message de file d'attente pourrait-il comporter des champs d'état, que les abonnés pourraient modifier au fur et à mesure qu'ils traitent leur partie du flux de travail ? ( ou le feriez-vous dans la base de données ? )

J'essaie juste d'obtenir des éclaircissements sur les cas où l'on utilise une file d'attente plutôt qu'une base de données.

Answer 1

Lorsqu'un processus souhaite confier des données et le traitement de ces données à un autre processus (éventuellement sur un hôte différent), il existe deux stratégies :

1. Placez toutes vos données dans la file d'attente et laissez l'application réceptrice s'occuper de les stocker dans la base de données, ainsi que de tout autre traitement.

2. Mettez à jour votre base de données, puis mettez en file d'attente un petit message à l'autre processus, juste pour l'informer qu'il y a de nouvelles données à traiter.

Un certain nombre de facteurs peuvent être utilisés pour décider de la stratégie à adopter :

• Si votre base de données est entièrement ACID (on peut l'espérer) mais que votre système de mise en file d'attente (QS) ne l'est pas, vos données seraient plus sûres dans la BD. Même si le message de la file d'attente est perdu dans un crash du serveur, vous pourriez exécuter un script pour traiter les données non traitées trouvées dans la BD. Ce serait un cas pour l'option 2.

• Si vos données sont assez volumineuses (disons 1 Mo ou plus), il peut être cruel d'en charger votre QS. Si elles sont persistantes, vous finirez par écrire les données deux fois, d'abord dans le persister du QS, puis dans la base de données. Cela pourrait nuire aux performances et vous inciter à choisir l'option 1.

• Si votre base de données est lente ou n'est même pas accessible au front-end de votre application, il faut choisir l'option 1.

• Si votre deuxième processus doit faire quelque chose avec les données mais ne les stocke pas dans une base de données, alors l'option 1 peut être la solution.

Je n'en vois pas d'autres, mais j'espère que vous avez saisi l'idée.

Answer 2

En général, une file d'attente est utilisée pour "lisser" le taux de publication par rapport au taux de consommation, en mettant en mémoire tampon les demandes entrantes qui ne peuvent pas être traitées immédiatement. Une file d'attente est généralement soutenue par une sorte de stockage non volatile (comme une table de base de données). La distinction n'est donc pas si nette.

Utilisez une base de données lorsque vous souhaitez effectuer de nombreuses recherches dans votre "file d'attente" ou fournir des rapports détaillés.

Answer 3

Je vous recommande de consulter le livre de Gregor Hophe, Modèles d'intégration d'entreprise qui explique de nombreux modèles différents pour les approches basées sur la messagerie.

Answer 4

Nous utilisions beaucoup JMS dans mon dernier emploi, où nous faisions circuler des données de machine à machine. Au final, nous envoyions et stockions les données en même temps, mais nous stockions beaucoup moins de données que nous n'en envoyions. Nous avions beaucoup de métadonnées autour des valeurs réelles.

Nous avons utilisé JMS comme un simple service de messagerie et il a très bien fonctionné pour cela. Mais vous ne voulez pas utiliser JMS pour stocker vos données car il n'a pas de persistance (à part la possibilité d'enregistrer et de rejouer les messages peut-être).

L'un des principaux avantages de JMS est la possibilité d'envoyer vos messages dans l'ordre correct et approprié et de s'assurer que tout le monde les reçoit dans cet ordre. Cela facilite la synchronisation puisque la majorité du traitement des messages est effectuée pour vous.

Answer 5

Si j'ai bien compris, Twitter utilisera à la fois la base de données et JMS. Tout d'abord, lorsque les tweets seront écrits, ils seront stockés dans la base de données et s'afficheront ainsi sur le tableau d'affichage. Cependant, comme il s'agit d'un modèle éditeur/abonné, lorsque les tweets sont publiés, ils sont ensuite envoyés aux abonnés. Les deux éléments seront donc utilisés.