Sequenzielle Hintergrundverarbeitung von Aufgaben unter Microsoft

Question

Ich muss in der Warteschlange befindliche Jobs der Reihe nach (oder mit n Threads parallel) im Hintergrund ausführen, um die Auslastung des Systems besser zu steuern.

Die Jobs werden in einer SQL Server 2008-Datenbank mit einer Tabelle als Warteschlange in die Warteschlange gestellt.

Ich brauche eine einfache "Engine", die Elemente aus der Warteschlange entfernt und einen Verarbeitungscode ausführt. Der Verarbeitungscode lautet C#/.net.

Meine Hauptanliegen sind Einfachheit, Testbarkeit, einfache Bereitstellung und Zuverlässigkeit.

Ich bin auf der Suche nach Empfehlungen für die Technologie, wie BizTalk oder vielleicht ein Windows-Dienst?

Answer 1

Hier sind einige Optionen für Sie, aber Writing a windows service ist die, die ich wählen würde. Überprüfen Sie den Link. Es gibt ein einfaches Beispiel und kann Ihnen den Einstieg erleichtern.

Eine andere Option wäre, SQL Server Agent als Scheduler zu verwenden, um bei Bedarf C# -Dateien abzufeuern. Allerdings ist dies keine gute Option, da es sich eher wie ein Hack für mich anfühlt.

Answer 2

Über welche Art von Jobs reden wir? Wenn die Jobs selbst aus Datenbankarbeit bestehen, ist es die beste Option, in SQL Server internal Activation zu nutzen. Die interne Aktivierung kann auch C# /. Net-Code starten. Ein Beispiel finden Sie unter Asynchronous procedure execution. Aktivierung ist der zuverlässigste Weg. Die geplanten Jobs können das Spiegeln und Cluster-Failover überleben. Tatsächlich ist es so zuverlässig, dass der geplante Job auch nach einem Serverabsturz und dem Wiederaufbau des Servers aus Datenbanksicherungen auf einem neuen Host aktiviert und ausgeführt wird. Dies sollte jedoch nicht verwendet werden, wenn die Arbeitsplätze "externe" Arbeit leisten müssen, z. Stellen Sie eine Verbindung zu einem Webdienst her. Für solche Dienste könnten Sie die External Activator verwenden und den Zuverlässigkeits- und Selbstbalancierungsskalierungsfaktor nutzen, der dem SQL Server-Aktivierungsmechanismus innewohnt, aber letztlich immer noch eine Windows-Service- und eine Service Broker-Warteschlange ist.

Wenn Sie den Overhead von integrierten SQL-Warteschlangen zu hoch finden, empfehle ich über Using tables as Queues gehen und versuchen, mit den Grundlagen zu bleiben. Fügen Sie keine ausgefallenen Peeks oder Scans über die Queue-Tabelle hinzu oder Ihr System wird von Deadlocks überschwemmt. Dies ist ein häufiges Problem bei der Verwendung von Tabellen als Warteschlangen.