Verwenden von SQL Server als DB-Warteschlange mit mehreren Clients

Ich empfehle Ihnen, Tabellen als Warteschlangen zu verwenden. Korrekt implementierte Warteschlangen können Tausende von gleichzeitigen Benutzern verarbeiten und bis zu 1/2 Million Enqueue/Dequeue-Operationen pro Minute verarbeiten. Bis SQL Server 2005 war die Lösung umständlich und beinhaltete das Mischen eines SELECT und ein UPDATE in einer einzigen Transaktion und geben Sie genau die richtige Mischung von Sperrhinweisen, wie in dem von gbn verlinkten Artikel. Glücklicherweise ist seit SQL Server 2005 mit dem Aufkommen der OUTPUT-Klausel eine viel elegantere Lösung verfügbar, und jetzt empfiehlt MSDN die Verwendung der OUTPUT-Klausel:

Sie können OUTPUT in Anwendungen verwenden, die Tabellen als Warteschlangen verwenden, oder um Zwischenergebnisse zu speichern. Das bedeutet, dass die Anwendung ständig Zeilen zur Tabelle hinzufügt oder entfernt

Grundsätzlich gibt es 3 Teile des Puzzles, die Sie richtig machen müssen, damit dies auf höchst gleichzeitige Weise funktioniert:

Sie müssen sich automatisch aus der Warteschlange entfernen. Sie müssen die Zeile finden, alle gesperrten Zeilen überspringen und sie in einer einzigen, atomaren Operation als „aus der Warteschlange entfernt“ markieren, und hier ist der OUTPUT Klausel ins Spiel kommt:

    with CTE as (
      SELECT TOP(1) COMMAND, PROCESSED
      FROM TABLE WITH (READPAST)
      WHERE PROCESSED = 0)
    UPDATE CTE
      SET PROCESSED = 1
      OUTPUT INSERTED.*;

Sie müssen Strukturieren Sie Ihre Tabelle mit dem gruppierten Indexschlüssel ganz links auf PROCESSED Säule. Wenn die ID als Primärschlüssel verwendet wurde, verschieben Sie ihn als zweite Spalte in den gruppierten Schlüssel. Die Debatte, ob ein nicht geclusterter Schlüssel auf der ID behalten werden soll Spalte ist offen, aber ich bevorzuge nicht irgendwelche sekundären nicht geclusterten Indizes über Warteschlangen haben:

    CREATE CLUSTERED INDEX cdxTable on TABLE(PROCESSED, ID);

Sie dürfen diese Tabelle auf keine andere Weise als durch Dequeue abfragen. Der Versuch, Peek-Operationen durchzuführen oder die Tabelle sowohl als Warteschlange als auch zu verwenden wie ein Geschäft sehr wahrscheinlich zu Deadlocks führen und den Durchsatz drastisch verlangsamen.

Die Kombination aus atomarem Dequeue, READPAST-Hinweis zum Suchen von Elementen zum Dequeue und Schlüssel ganz links im Clustered-Index basierend auf dem Verarbeitungsbit gewährleistet einen sehr hohen Durchsatz bei hochgradig gleichzeitiger Last.