Gibt es ein Standardmuster für das Scannen einer Jobtabelle, die einige Aktionen ausführt?

(Ich merke, dass mein Titel schlecht ist.Wenn nach dem Lesen der Frage hast du eine Verbesserung im Kopf, bitte entweder bearbeiten oder erzählen Sie mir und ich werde es ändern.)

Ich habe das relativ häufige Szenario einer Job-Tabelle, die 1 Zeile für etwas, was getan werden muss. Zum Beispiel könnte es eine list von E-Mails zu senden. Der Tisch sieht so aus:

ID Completed TimeCompleted anything else... ---- --------- ------------- ---------------- 1 No blabla 2 No blabla 3 Yes 01:04:22 ... 

Ich suche entweder für eine Standardpraxis / Muster (oder Code – C # / SQL server bevorzugt) für periodisch "Scannen" (ich benutze den Begriff "Scannen" sehr lose) diese Tabelle, die search nach den nicht abgeschlossenen Items, die Aktion zu tun und dann markiert sie abgeschlossen, sobald es erfolgreich gemacht wurde.

Neben dem Grundprozess für die Erfüllung der oben genannten, erwäge ich die folgenden Anforderungen:

  • Ich möchte irgendwelche Mittel von "Skalierung linear", zB laufen mehrere "Worker processe" gleichzeitig oder Threading oder was auch immer. (Nur ein bestimmter technischer Gedanke – ich gehe davon aus, dass ich als Ergebnis dieser Anforderung eine Methode zur Markierung eines Artikels als "in Bearbeitung" benötige, um zu vermeiden, dass die Aktion mehrmals versucht wird.)
  • Jedes Element in der Tabelle sollte nur einmal ausgeführt werden.

Einige andere Gedanken:

  • Ich bin nicht besonders besorgt über die Implementierung in der database (zB in T-SQL oder PL / SQL-Code) vs. einige externe Programmcode (zB eine eigenständige ausführbare file oder eine Aktion, die durch eine Webseite ausgetriggers wird), die ausgeführt wird die database
  • Ob das "Tun der Action" -Teil synchron oder asynchronous gemacht wird, ist nicht etwas, das ich als Teil dieser Frage betrachte.

Solutions Collecting From Web of "Gibt es ein Standardmuster für das Scannen einer Jobtabelle, die einige Aktionen ausführt?"

Wenn Sie bereit sind, Nicht-database-Technologien zu betrachten, ist die beste (wenn auch nicht die einzige) Lösung Message Queuing (oft in Verbindung mit einer database, die die einzelnen Details enthält). Message-Warteschlangen bieten eine Menge functionalität, aber der grundlegende Workflow ist einfach:

1) Ein process stellt eine "Job-Nachricht" (vielleicht nur eine ID) auf eine Warteschlange.

2) Ein weiterer process hält ein Auge auf die Warteschlange. Es befragt die Warteschlange für die Arbeit, und zieht Arbeitsplätze, die es aus der Warteschlange findet, eine zu einer time, in der Reihenfolge, in der sie empfangen wurden. Gegenstände, die Sie aus der Warteschlange abgezogen haben, werden effektiv als "in Arbeit" markiert – sie stehen nicht mehr für andere processe zur Verfügung.

3) Für kritische Workflows können Sie im Falle eines Systemerrorss eine Transaktions-Read-In-function durchführen, die Transaktion rollt zurück und die Nachricht befindet sich noch in der Warteschlange. Wenn es irgendeine andere Art von exception gibt (wie ein Timeout während einer database lesen), können Sie einfach die Nachricht an eine spezielle Fehler-Warteschlange weiterleiten.

Der einfachste path, um dies zu skalieren ist, dass Ihr Leser process Versand mehrere Threads zu behandeln Arbeitsplätze, die es zieht aus der Warteschlange. Alternativ können Sie mit mehreren Leserprozessen skalieren, die sich auf separaten servern befinden können.

.NET-Unterstützung umfasst Microsoft Message Queue und Windows Communication Foundation oder die classn im Namespace System.Messaging. Es erfordert einige Setup und configuration (Sie müssen die Warteschlangen erstellen und permissions konfigurieren), aber es lohnt sich.

Um zu skalieren, möchten Sie vielleicht prüfen, scannen nach Jobs, die bereit sind, dann fügen Sie sie zu einer Nachricht Warteschlange. Auf diese Weise können mehrere Verbraucher fertige Jobs aus der Warteschlange lesen. Das Markieren von Aufträgen als "in Bearbeitung" könnte so einfach sein, dass dieser Wert in die Spalte "Abgeschlossen" gesetzt wurde, oder Sie können eine Spalte "TimeStarted" hinzufügen und eine vorgegebene timeüberschreitungsperiode haben, bevor ein Job zurückgesetzt wird und für einen anderen Worker-Thread zugelassen werden kann . (Der letztgenannte Ansatz geht davon aus, dass die Verarbeitung fehlgeschlagen ist, wenn die time verstrichen ist, ohne dass der Job abgeschlossen ist. Das Fehlen nach einer Anzahl von Versuchen sollte eine manuelle Inspektion dieses Auftrags erfordern.) Der gleiche Daemon-process, der die database für die fertigen Jobs scannt, um die Warteschlange hinzuzufügen, kann suche nach Jobs, die abgelaufen sind.

Wenn Sie SQL 2005+ verwenden, können Sie Service Broker untersuchen . Es ist so ziemlich dafür gedacht.