Je vous recommande d'aller sur Utilisation des tables comme files d'attente. Les files d'attente correctement mises en œuvre peuvent gérer des milliers d'utilisateurs simultanés et un service pouvant atteindre 1/2 million d'opérations de mise en file d'attente/de retrait de la file d'attente par minute. Jusqu'à SQL Server 2005, la solution était lourde et impliquait de mélanger un SELECT et une UPDATE en une seule transaction et donnez juste la bonne combinaison d'indices de verrouillage, comme dans l'article lié par gbn. Heureusement, depuis SQL Server 2005 avec l'avènement de la clause OUTPUT, une solution beaucoup plus élégante est disponible, et maintenant MSDN recommande d'utiliser la clause OUTPUT :
Vous pouvez utiliser OUTPUT dans les applications qui utilisent des tables comme files d'attente ou pour conserver des ensembles de résultats intermédiaires. Autrement dit, l'application ajoute ou supprime constamment des lignes de la table
Fondamentalement, il y a 3 parties du puzzle que vous devez résoudre pour que cela fonctionne de manière hautement simultanée :
- Vous devez retirer la file d'attente automatiquement. Vous devez trouver la ligne, ignorer toutes les lignes verrouillées et la marquer comme « retirée de la file d'attente » en une seule opération atomique, et c'est là que le
OUTPUTclause entre en jeu :
with CTE as (
SELECT TOP(1) COMMAND, PROCESSED
FROM TABLE WITH (READPAST)
WHERE PROCESSED = 0)
UPDATE CTE
SET PROCESSED = 1
OUTPUT INSERTED.*;
- Vous devez structurez votre table avec la clé d'index clusterisée la plus à gauche sur le
PROCESSEDcolonne. Si l'IDa été utilisée comme clé primaire, puis déplacez-la comme deuxième colonne dans la clé groupée. Le débat sur l'opportunité de conserver une clé non clusterisée sur l'IDla colonne est ouverte, mais je préfère fortement ne pas avoir des index secondaires non clusterisés sur les files d'attente :
CREATE CLUSTERED INDEX cdxTable on TABLE(PROCESSED, ID);
- Vous ne devez pas interroger cette table par d'autres moyens que par Dequeue. Essayer d'effectuer des opérations Peek ou essayer d'utiliser la table à la fois comme file d'attente et car un magasin le fera très probablement entraînera des blocages et ralentira considérablement le débit.
La combinaison du retrait atomique de la file d'attente, de l'indice READPAST pour rechercher des éléments à retirer de la file d'attente et de la clé la plus à gauche sur l'index clusterisé en fonction du bit de traitement garantit un débit très élevé sous une charge hautement simultanée.
