Message Queue. Base de données vs MQ dédié

Je suis à la recherche de conseils concernant la mise en file d'attente des messages. Nous avons des exigences pour que les "travaux" soient publiés dans une file d'attente de messages.

La suggestion initiale consistait simplement à utiliser une instance SQL Server et à traiter les messages de celle-ci. Tout ce que j'ai lu sur Internet suggère que l'utilisation d'une base de données pour une file d'attente de messages n'est pas une solution évolutive. Pour cette raison, l'idée d'utiliser RabbitMQ ou un autre MQ tiers a été suggérée.

L'autre chose à prendre en compte est que l'exigence de "traitement des travaux" ne sera pas inférieure à 30 secondes, donc le processus qui effectue le travail interrogera la base de données toutes les 30 secondes. Pour moi, cela ne semble pas si mal et fonctionnerait probablement bien sans ajouter une charge importante à la base de données.

Nous avons déjà une base de données en place sur nos clients que nous pourrions utiliser pour cela, donc cela n'ajoutera pas beaucoup de support supplémentaire requis à nos clients, alors que si nous ajoutions un MQ tiers, il y aurait un support supplémentaire pour la configuration du réseau, etc., ce qui serait considérable étant donné qu'il y a beaucoup d'utilisateurs.

L'autre option que j'envisageais était de permettre aux utilisateurs de choisir entre les deux. S'ils sont un petit utilisateur, la solution Sql Server sera correcte, mais s'ils sont un plus grand utilisateur, nous leur permettons de configurer une solution MQ tierce.

Je ne suis pas vendu sur une solution, je me demande si quelqu'un a quelque chose à considérer ou à conseiller.

Tout ce que j'ai lu sur Internet suggère que l'utilisation d'une base de données pour une file d'attente de messages n'est pas une solution évolutive.

La réalité souvent ignorée par la foule « n'utilisez pas X parce qu'il ne se redimensionne pas » (le lien contient un langage que certains peuvent trouver répréhensible) est que le redimensionnement n'est pas toujours important. J'irais jusqu'à dire que si vous regardez toutes les applications sur la surface de la planète, l'échelle est rarement importante.

Votre commentaire cite un taux de 20 000 messages par jour, ce qui signifie que vous envisagez de prendre en charge un taux moyen de 0,23 messages par seconde (un toutes les 4,3 secondes). Si votre projet s'avère deux fois plus efficace que prévu, vos besoins passent au traitement de 23 messages par seconde, ce que je serais très à l'aise de confier à mon téléphone portable de quatre ans ou à une framboise. Pi. Ce n'est toujours pas une application à grande échelle même si vous clouez dessus quelques autres ordres de grandeur.

J'ai vu (heureusement, en marge) des projets qui se terminent mal parce qu'ils ont passé trop de temps trop tôt à obséder sur l'échelle qui ne se produirait pas ou pas de temps à ce sujet et se sont retrouvés écrasés par l'échelle qui l'a finalement fait. Comme tout le reste, il existe un juste milieu. Si vous pensez qu'une mise à l'échelle à grande échelle pour votre application est une possibilité réaliste, il ne devrait pas être difficile de faire une analyse de rentabilisation pour faire le peu de travail supplémentaire nécessaire pour créer suffisamment d'abstraction autour de parties non évolutives qui sont peu coûteuses à déployer maintenant . Cela signifie que plus tard , si un besoin d'évolutivité devait survenir, vous avez un moyen (et éventuellement les revenus) pour effectuer le remplacement en gros de ces pièces sans avoir à repenser l'ensemble du système.

Bien que le volume de messages de votre application ne fasse pas suer une base de données ou un système de mise en file d'attente de messages, même sur un matériel modeste, vous avez probablement d'autres exigences concernant la façon dont vos transactions de messages sont gérées qui font de l'un ou de l'autre un meilleur choix. Ces exigences sont ce que vous devriez évaluer.

Les files d'attente de messages prennent tout leur sens lorsque vous en avez plusieurs et acheminez les messages entre elles, en les déployant vers plusieurs consommateurs, etc.

Si vous n'avez qu'une seule «file d'attente de travaux» de choses que vous souhaitez traiter «hors ligne», une table SQL fera très bien l'affaire.

N'oubliez pas de vous assurer d'avoir un moyen de marquer les travaux en cours, de nettoyer les anciens et d'alerter lorsque le système s'arrête. Mais pour une seule file d'attente, la gestion manuelle de ces éléments nécessitera moins de travail que la maintenance d'une solution de mise en file d'attente distincte.

Comme d'autres l'ont mentionné, l'échelle n'est probablement pas importante ici. Le problème avec l'utilisation de deux mécanismes de stockage différents est l'intégrité transactionnelle.

Si vous utilisez une file d'attente de messages dédiée, vous devez choisir l'une des options suivantes en cas d'échec.

1. Autoriser que les données puissent être sur mb mais pas sur db
2. Autoriser que les données puissent être en db mais pas en mb
3. Configurer la validation en deux phases ou les transactions distribuées entre db et mq, ce qui peut être compliqué

Tous ces problèmes disparaissent si vous enregistrez les données en un seul endroit à l'aide d'une transaction normale. Pour cette raison, l'utilisation de db comme file d'attente de tâches est une solution parfaitement adaptée.

Pour des raisons pratiques, les principales raisons pour lesquelles j'utilise une file d'attente de messages sont:

• Je n'ai pas eu à réinventer la roue. Concevoir même la file d'attente de messages la plus simple à l'aide d'une base de données nécessite au moins quelques heures de réflexion, quelques heures de codage, etc. Comparé à l'implémentation d'une file d'attente de messages, le temps requis pour configurer et / ou automatiser la configuration est trivial
• Les files d'attente de messages ont une interface agréable et claire pour le producteur et le consommateur. C'est probablement la chose la plus importante lors de l'écriture d'une application. Sans l'interface, les files d'attente de messages ne sont essentiellement qu'une collection de données
• Les files d'attente de messages offrent plus de fonctionnalités qui pourraient être nécessaires à l'avenir

S'agissant de permettre aux utilisateurs de choisir, c'est vraiment un détail d'implémentation dont les utilisateurs ne devraient pas se soucier. Les utilisateurs doivent obtenir la même interface et il ne devrait y avoir aucune différence pour les utilisateurs si la base de données ou la file d'attente de messages est utilisée. Une fois qu'une conception unique est définie, un choix probable pour les utilisateurs est le nombre de nœuds à déployer pour répondre à leurs besoins.

J'ai créé une solution de file d'attente de messages Mssql qui peut gérer 20 000 opérations par seconde, selon un test de performance, et nous avons besoin de 10 / sec la plupart du temps. Je pense que le fait que vous puissiez réellement avoir une priorité intégrée est une fonctionnalité qui manque à la file d'attente de messages dédiée. Et c'était une exigence majeure dans mon cas.