Création d'un système de traitement des éléments de travail avec la sémantique FIFO modifiée dans Windows

Question

Je crée un système qui génère des "éléments de travail" qui sont mis en file d'attente pour le traitement back-end. J'ai récemment terminé un système qui avait les mêmes exigences et qui a été conçu avec une architecture que je ne trouve pas optimale et j'espérais obtenir des conseils pour ce nouveau système.

Les éléments de travail sont placés en file d'attente et doivent être traités dans un ordre essentiellement FIFO. Si c'était la seule exigence, alors je préférerais probablement une solution MSMQ ou SQL Server Service Broker. Cependant, en réalité, j'ai besoin de sélectionner des éléments de travail dans un ordre FIFO modifié. Un élément de travail a plusieurs attributs, et ils doivent être affectés dans l'ordre FIFO où certaines combinaisons de valeurs d'attribut existent. Par exemple, un élément de travail peut avoir les attributs suivants: Bureau, Priorité, Numéro de groupe et Numéro de séquence (dans le groupe)

Par exemple, un élément de travail peut avoir les attributs suivants: Bureau, Priorité, Numéro de groupe et Numéro de séquence (dans le groupe). Lorsque plusieurs éléments sont mis en file d'attente pour le même numéro de groupe, ils sont garantis d'être mis en file d'attente dans l'ordre du numéro de séquence et ont la même priorité.

Il existe plusieurs processus dorsaux (actuellement implémentés en tant que services Windows) qui génèrent des temps de travail dans l'ordre FIFO modifié en fonction de certains paramètres de configuration pour le service donné. Le service qui exécute Washington, DC est configuré pour traiter uniquement les éléments de travail pour DC, tandis que le service dans NY peut être configuré pour traiter les éléments NY et DC (principalement pour augmenter le débit global). En plus de ce type de sélectivité, les éléments de priorité supérieure doivent être traités en premier, et les éléments qui contiennent le même "numéro de groupe" doivent être traités dans l'ordre du numéro de séquence. Donc, si le service NY travaille sur un élément DC du groupe 100 avec la séquence 1, je ne veux pas que le service DC retire l'élément DC dans la séquence du groupe 100 2 parce que la séquence 1 n'est pas encore terminée. Les éléments d'autres groupes doivent rester éligibles pour le traitement.

Dans le dernier système, j'ai implémenté les files d'attente avec les tables SQL. J'ai créé des procédures stockées pour soumettre des articles et, plus important encore, pour "assigner" des articles aux services Windows qui étaient chargés de les traiter. Les procédures stockées d'affectation contiennent la logique de sélection que j'ai décrite ci-dessus. Chaque service Windows appelait la procédure stockée d'affectation en lui transmettant les paramètres uniques à cette instance du service (par exemple, les bureaux éligibles). Cette procédure stockée d'affectation estampille l'élément de travail comme affecté (en cours) et lorsque le travail est terminé, une procédure stockée finale est appelée pour retirer l'élément de la "file d'attente" (table).

Cette solution présente certains avantages dans la mesure où je peux rapidement examiner l'état de ces "files d'attente" par une simple instruction de sélection SQL. Je suis également capable de manipuler les files d'attente facilement (par exemple, je peux augmenter les priorités avec une simple instruction de mise à jour SQL). Cependant, à la baisse, il m'arrive de devoir faire face à des deadlocks sur ces tables de files d'attente et d'écrire ces procédures stockées (ce qui devient fastidieux au bout d'un moment).

D'une manière ou d'une autre, je pense que MSMQ (avec ou sans WCS) ou Service Broker devrait être capable de fournir une solution plus élégante. Faire rouler mon propre système de file d'attente/de traitement des éléments de travail me donne tort. Mais autant que je sache, ces technologies n'offrent pas la flexibilité dont j'ai besoin dans le processus d'affectation. J'espère que j'ai tort. N'importe quel conseil est le bienvenu.

Answer 1

Les files d'attente sont pour l'ordre FIFO, pas pour l'accès aléatoire. Même si vous dites que vous voulez l'ordre FIFO, vous voulez l'ordre FIFO par rapport à un ensemble aléatoire de variables, qui est essentiellement ordre aléatoire. Si vous voulez utiliser des files d'attente, vous devez être en mesure de déterminer l'ordre avant que le message n'entre dans la file.

Answer 2

Il me semble que votre concept d'unité de travail atomique est un groupe. Donc, je suggère que vous ne faites que mettre en file d'attente un message qui identifie un identifiant de groupe, puis votre travailleur devra aller à une table qui mappe l'ID de groupe à 1 ou plusieurs éléments de travail.

Vous pouvez gérer vos autres problèmes en utilisant plus d'une file d'attente - NY-haut, NY-bas, DC-haut, DC-bas, etc.

En toute honnêteté, cependant, je pense que vous êtes mieux servi à résoudre vos problèmes de blocage dans votre architecture actuelle. Vous devriez lire le message TOP 1 de votre table de file d'attente avec les indicateurs de verrouillage de mise à jour et de lecture passée, classés par votre logique de priorité et les critères de filtre que vous voulez (bureau/emplacement). Ensuite, vous traitez votre message, changez son statut ou déplacez-le vers une autre table. Vous devriez être capable d'appeler cette procédure stockée en parallèle sans problème de blocage.