RabbitMQ - autoriser un seul processus par utilisateur

Question

Pour faire court, voici une situation simplifiée :

Je dois mettre en place une file d'attente pour le traitement en arrière-plan des fichiers de données importés. Je veux dédier un certain nombre de consommateurs à cette tâche spécifique (disons 10) afin que plusieurs utilisateurs puissent être traités en parallèle. En même temps, pour éviter les problèmes d'écriture simultanée de données, je dois m'assurer qu'aucun utilisateur n'est traité par plusieurs consommateurs en même temps, en fait tous les fichiers d'un même utilisateur doivent être traités séquentiellement.

Solution actuelle (mais cela ne semble pas correct) :

• Avoir 1 file d'attente où toutes les tâches d'importation sont publiées ( file_queue_main )
• Avoir 10 files d'attente pour le traitement des fichiers ( file_processing_n )
• Avoir 1 file d'attente de résultats ( file_results_queue )
• Avoir un processus de gestion (dans ce cas dans node.js ) qui consomme les messages de file_queue_main un par un et décide à quelle file_processing pour distribuer ce message. En fait, il garde la trace de l'endroit dans lequel file_processing les files d'attente que l'utilisateur actuel est en train de traiter.

Voici une petite animation de ma solution actuelle et du comportement attendu :

RabbitMQ est-il vraiment l'outil qu'il faut pour ce travail ? Pour une raison quelconque, j'ai l'impression que c'est une sorte d'anti-modèle. Toute aide est la bienvenue !

Answer 1

La partie qui ne me semble pas correcte est le processus de gestion. Il doit connaître l'état actuel de chaque consommateur, et il doit également s'arrêter et attendre si tous les processeurs travaillent sur d'autres utilisateurs. Idéalement, vous préféreriez que chaque processus ignore tout des autres. Vous obtenez également très peu de bénéfices de vos files d'attente de traitement, qui ne sont utilisées que lorsqu'un processeur travaille déjà sur un message du même utilisateur.

En fin de compte, la meilleure solution ici va dépendre de l'utilisation que vous prévoyez et de la probabilité que le prochain message provienne d'un utilisateur déjà en cours de traitement. Si vous vous attendez à ce que la plupart des messages que vous recevez à un moment donné proviennent de 10 utilisateurs ou moins, votre solution peut convenir. Si vous prévoyez de traiter des messages provenant de nombreux utilisateurs différents, avec seulement quelques doublons occasionnels, vos files d'attente de traitement seront vides la plupart du temps et vous aurez créé une complexité inutile.

D'autres choses que vous pourriez faire ici :

• Faites en sorte que tous les consommateurs tirent de la même file d'attente et utilisez une sorte de verrouillage distribué pour éviter les collisions. Si un consommateur reçoit un message d'un utilisateur qui est déjà en cours de traitement, il le remet en file d'attente et passe à autre chose.

• Configurez le routage de votre file d'attente de sorte que les messages d'un même utilisateur aillent toujours au même consommateur. L'inconvénient, c'est que si vous ne répartissez pas le trafic de façon homogène, certains consommateurs peuvent être surchargés alors que d'autres restent inactifs.

De plus, si vous recevez en même temps de nombreux messages du même utilisateur qui doivent être traités de manière séquentielle, je me demande si ces messages doivent être séparés. Pourquoi ne pas envoyer un seul message avec une liste de choses à traiter ? Une grande partie de l'avantage des files d'attente d'événements provient de la possibilité de traiter chaque événement comme un élément discret qui peut être traité individuellement.

Answer 2

Si l'utilisateur a un identifiant unique, ou si le fichier sur lequel il travaille a un identifiant unique, hacher l'identifiant pour obtenir la file d'attente de traitement à saisir. De cette façon, vous aurez toujours le même utilisateur / la même tâche sur le fichier dans la même file d'attente de traitement.

Je ne suis pas sûr de l'effet que cela aura sur la longueur des files d'attente de traitement.