Files d'attente contre des tables dans des systèmes de messagerie [fermé]

Question

J'ai rencontré les avantages et les inconvénients des systèmes de messagerie dans des environnements de production réels , et je dois admettre qu'une table bien organisée ou un schéma de tables bat tout simplement à chaque fois que toute autre forme de file d'attente de messagerie, car:

1. Les données sont stockées en permanence sur une table. J'ai vu tellement d'applications java (jms) perdre ou supprimer des messages en route pour des exceptions non détectées ou d'autres bogues.
2. Les files d'attente ont tendance à se remplir. Le stockage Db est pratiquement infini à la place.
3. Les tables sont facilement accessibles, mais vous devez utiliser des instruments ésotiques pour lire dans une file d'attente.

Que pensez-vous de chaque approche?

Answer 1

La phrase bat à chaque fois dépend entièrement de vos besoins. Certes, il ne va pas battre chaque fois pour tout le monde.

Si vous construisez un seul système qui utilise déjà une base de données, vos besoins en débit et performances ne sont pas très élevés et vous n'avez pas à communiquer avec d'autres équipes ou systèmes, vous avez probablement raison.

Pour une base de données simple et basse, principalement à un seul thread, la base de données constitue une alternative totalement intéressante aux files d'attente de messages.

Une file de messages brillante est quand

• vous souhaitez un équilibreur de charge hautes performances, hautement concurrentiel et évolutif, afin que vous puissiez traiter simultanément des dizaines de milliers de messages sur plusieurs serveurs / processus (à l'aide d'une table de base de données, vous auriez la chance de traiter quelques centaines de secondes et plus. le traitement avec plusieurs threads est assez difficile, car un processus a tendance à verrouiller la table des files de messages)
• vous devez communiquer entre différents systèmes en utilisant différentes bases de données (vous n'avez donc pas besoin de donner un accès en écriture à la base de données de votre système à d'autres personnes appartenant à des équipes différentes, etc.)

Pour les systèmes simples avec une base de données unique, une équipe et des exigences de performances relativement modestes, utilisez une base de données. Utilisez le bon outil pour le travail, etc.

Toutefois, les files d'attente de messages brillent dans les grandes organisations où de nombreux systèmes doivent communiquer entre eux (et vous ne souhaitez donc pas qu'une base de données métier soit le point central de la panne ou de la version enfer) ou lorsque vous avez des exigences de performances élevées.

En termes de performances, une file de messages bat toujours une table de base de données. En effet, les files de messages sont spécifiquement conçues pour le travail et ne reposent pas sur des verrous de table pessimistes (requis pour l'implémentation d'une base de données dans une base de données). équilibrage de charge) et les bonnes files d'attente de messages effectueront un chargement rapide des messages dans les files d'attente éviter la surcharge réseau d'une base de données .

De même, vous n'utiliseriez jamais de base de données pour équilibrer la charge des demandes HTTP sur vos serveurs Web, car cela serait trop lent: si vous avez des exigences de performances élevées pour votre équilibreur de charge, vous n'utiliseriez pas non plus de base de données. .

Answer 2

J'ai d'abord utilisé les tables, puis refactorisées dans une file d'attente de messages complète lorsque (et si) il y a une raison - ce qui est trivial si votre conception est raisonnable.

Les principaux avantages sont a.) C’est plus facile (b. c’est une meilleure piste d’audit car vous devez joindre les autres tables, c.) si vous connaissez très bien les outils de base de données, ils sont plus faciles à utiliser que les outils. Outils Message Queue, d.) Il est généralement un peu plus facile de configurer un environnement test / dev dans un contexte qui existe déjà pour votre application (si la même familiarité s'applique).

Oh, et e.) pour vous et d'autres peut-être, ce n'est pas un autre produit à apprendre, à installer, à configurer, à administrer et à supporter.

IMPE, c’est tout aussi fiable, déconnectable et vous pouvez convertir si cela nécessite davantage de mise à l’échelle.

Answer 3

1. Les données sont stockées en permanence sur une table. J'ai vu tellement d'applications java (jms) perdre des messages ou les effacer, pour des exceptions non détectées ou d'autres bugs.

   Quelle implémentation JMS? Sun vend des files d'attente fiables qui ne peuvent pas perdre de messages. Vous venez peut-être d'acheter un produit ringard conforme à JMS. Le MQ d’IBM est extrêmement fiable et il existe des bibliothèques JMS pour y accéder.

2. Les files d'attente ont tendance à se remplir. Le stockage Db est pratiquement infini, à la place.

   Ummm ... Si votre file d'attente est pleine, il semblerait que quelque chose soit cassé. Si vos applications se bloquent, ce n'est pas une bonne chose, et les files d'attente ont peu à voir avec cela. Si vous avez acheté une implémentation JMS vraiment médiocre, je peux voir où vous pourriez ne pas être satisfait. C'est un marché concurrentiel. Trouvez un meilleur gestionnaire de files d'attente. JCAPS de Sun possède un très bon gestionnaire de files d'attente, anciennement la file de messages SeeBeyond.

3. Les tables sont facilement accessibles, mais vous devez utiliser des instruments ésotiques pour les lire dans une file d'attente.

   Cela ne correspond pas à mon expérience. Les tables sont accessibles via cette étrange "autre langue". (SQL), et nécessite que je connaisse les mappages de structure des tables aux objets et les mappages de types de données de VARCHAR2 à String. De plus, je dois utiliser une sorte de couche d'accès (JDBC ou un ORM utilisant JDBC). Cela semble très, très complexe. Une file d'attente est accessible via MessageConsumers et MessageProducers à l'aide de simples envois et réceptions.

Answer 4

Il semble que les problèmes que vous avez rencontrés ne soient pas inhérents à la messagerie, mais plutôt à des artefacts de systèmes de messagerie mal implémentés. La construction de systèmes de messagerie est-elle plus difficile que la construction de bases de données? Oui, si vous ne faites que construire des systèmes de base de données.

• Perdre des messages à des exceptions non interceptées? Ce n'est pas la faute de la file d'attente des messages. Les applications que vous utilisez sont mal conçues. Ils suppriment les messages de la file d'attente avant la fin du traitement. Ils n'utilisent pas de transactions ou de journalisation.
• Les files de messages se remplissent tandis que le stockage de la base de données est "pratiquement infini"? Vous parlez comme si la gestion de l’espace disque n’était pas nécessaire. Les serveurs de files de messages nécessitent une administration, tout comme les serveurs de base de données.
• Des instruments ésotériques à lire dans une file d'attente? Peut-être que si vous trouvez des méthodes asynchrones ésotériques. Peut-être si vous trouvez la sérialisation et la désérialisation ésotériques. (Au moins, c’est ce que j’ai trouvé ésotérique lorsque j’apprenais la messagerie. Comme beaucoup de technologies apparemment ésotériques, elles sont en réalité assez banales une fois que vous les comprenez, et les comprendre est une partie importante de la formation du développeur chevronné.)

Aspects de la messagerie qui la rendent supérieure aux bases de données:

• Traitement asynchrone. Les files d'attente de messages informent les processus en attente de l'arrivée de nouveaux messages. Pour accomplir cette fonctionnalité dans une base de données, les processus en attente doivent interroger la base de données.
• Séparation des problèmes. Le canal de communication est découplé des détails de mise en œuvre du contenu du message. Seuls l'expéditeur et le destinataire ont besoin de connaître le format du flux de données dans un message donné.
• Tolérance aux pannes. . La messagerie peut fonctionner lorsque les connexions entre les serveurs sont intermittentes. Les files de messages peuvent stocker des messages localement et les transférer aux serveurs distants uniquement lorsque la connexion est établie.
• Intégration de systèmes. Dans le monde Windows, au moins, la messagerie est intégrée au système d'exploitation. Il utilise le modèle de sécurité du système d'exploitation, il est géré à l'aide des outils du système d'exploitation, etc.

Si vous n'avez pas besoin de ces choses, vous n'avez probablement pas besoin de messagerie.

Voici un exemple simple d’application de messagerie: je suis en train de construire un système dans lequel les utilisateurs, répartis sur plusieurs réseaux, saisissent des ensembles assez complexes de transactions utilisées pour produire une sortie imprimée. La génération de sortie est coûteuse en termes de calcul et ne fait pas partie de leur flux de travail; c'est-à-dire que les utilisateurs ne s'inquiètent pas du moment où la sortie est générée, mais le fait même.

Nous allons donc sérialiser les transactions dans un message et le déposer dans une file d'attente. Un processus exécuté sur un serveur récupère les messages de la file d'attente, génère la sortie et la stocke dans un système de création d'image.

Si nous utilisions une base de données comme banque de messages, il nous faudrait un schéma pour stocker un format de transaction qui, pour le moment, ne concerne que l'expéditeur et le destinataire, nous devons nous assurer que chaque poste de travail du poste réseau avait des connexions permanentes permanentes au serveur de base de données, nous n'aurions pas la capacité de répartir cette charge de transaction sur plusieurs serveurs et notre serveur de sortie devrait interroger la base de données des milliers de fois par jour en attendant de savoir s'il y avait de nouveaux travaux à traiter .

Answer 5

Les files d'attente fournissent une messagerie fiable. La mise en file d'attente déconnectée et en différé la rend beaucoup plus évolutive que les bases de données, sans parler de sa robustesse.

Et les files d’attente ne doivent pas vraiment être utilisées pour le stockage permanent d’informations - il est préférable de les considérer comme des boîtes de réception temporaires, contrairement aux bases de données.