Ich liebe es, SQL Server-Code zu ändern, um die Leistung zu verbessern, aber es gibt gelegentlich Szenarien, in denen selbst nach dem Optimieren des Codes, der Indizes und des Designs eine Benutzeraufgabe aus der Anwendung länger dauert als die erwartete Endbenutzererfahrung. In diesem Fall muss die Benutzeroberfläche entweder warten, bis der Prozess abgeschlossen ist, oder wir müssen eine alternative Methode zur Handhabung der Aufgabe finden. Die von Service Broker bereitgestellte asynchrone Verarbeitung eignet sich gut für viele dieser Szenarien und ermöglicht die Hintergrundverarbeitung der lang andauernden Aufgabe getrennt von der Benutzeroberfläche, sodass der Benutzer sofort weiterarbeiten kann, ohne auf die tatsächliche Ausführung der Aufgabe warten zu müssen . Ich hoffe, in meinen nächsten Artikeln eine Reihe darüber erstellen zu können, wie Sie Service Broker mit den entsprechenden Erklärungen und Codebeispielen nutzen können, um die Nutzung der Funktionen von Service Broker ohne Implementierungsprobleme zu vereinfachen.
Methoden zur Durchführung asynchroner Verarbeitung
Es gibt eine Reihe von Möglichkeiten, mit einem lang andauernden, aber bereits abgestimmten Prozess umzugehen. Der Anwendungscode kann auch neu geschrieben werden, um einen BackgroundWorker, den Hintergrund-ThreadPool oder eine manuell geschriebene Thread-basierte Lösung in .NET zu verwenden, die den Vorgang asynchron ausführt. Dies ermöglicht jedoch, dass eine unbegrenzte Anzahl dieser lang laufenden Prozesse von der Anwendung übermittelt wird, es sei denn, es wird zusätzliche Codierungsarbeit geleistet, um die Anzahl aktiver Prozesse zu verfolgen und zu begrenzen. Dies bedeutet, dass die Anwendung potenzielle Auswirkungen auf die Leistung hat oder unter Last an eine Grenze stößt und zu dem vorherigen Warten zurückkehrt, das wir ursprünglich verhindern wollten.
Ich habe auch gesehen, dass diese Art von Prozessen in SQL Agent-Jobs umgewandelt wurden, die an eine Tabelle gebunden sind, die zum Speichern der zu verarbeitenden Informationen verwendet wird. Dann wird der Job entweder periodisch ausgeführt oder von der Anwendung mit sp_start_job gestartet wenn eine Änderung zur Verarbeitung gespeichert wird. Dies ermöglicht jedoch nur eine serielle Ausführung der lang laufenden Prozesse, da der SQL-Agent nicht zulässt, dass ein Job mehrmals gleichzeitig ausgeführt wird. Der Job müsste auch für Szenarien ausgelegt sein, in denen mehrere Zeilen in die Verarbeitungstabelle eingehen, damit die Verarbeitung in der richtigen Reihenfolge erfolgt und nachfolgende Übermittlungen separat verarbeitet werden.
Durch die Nutzung von Service Broker für die asynchrone Verarbeitung in SQL Server werden die Einschränkungen mit den zuvor erwähnten Methoden zur Handhabung der asynchronen Verarbeitung tatsächlich behoben. Die Broker-Implementierung ermöglicht das Einreihen neuer Aufgaben in die Warteschlange für die asynchrone Verarbeitung im Hintergrund sowie die parallele Verarbeitung der in die Warteschlange gestellten Aufgaben bis zu einem konfigurierten Limit. Anders als die Anwendungsschicht, die warten muss, wenn das Limit erreicht ist, stellt die Broker-Lösung die empfangene neue Nachricht einfach in die Warteschlange und lässt sie verarbeiten, wenn eine der aktuellen Verarbeitungsaufgaben abgeschlossen ist – dies ermöglicht der Anwendung, ohne Wartezeit fortzufahren /P>
Single Database Service Broker-Konfiguration
Während Service Broker-Konfigurationen komplex werden können, müssen Sie für eine einfache asynchrone Verarbeitung nur die grundlegenden Konzepte zum Erstellen einer einzelnen Datenbankkonfiguration kennen. Eine einzelne Datenbankkonfiguration erfordert nur:
- Zwei Nachrichtentypen erstellen
- Eine zum Anfordern der asynchronen Verarbeitung
- Eine für die Rückmeldung, wenn die Verarbeitung abgeschlossen ist
- Ein Vertrag, der die Nachrichtentypen verwendet
- Definiert, welcher Nachrichtentyp vom Initiatordienst gesendet und welcher Nachrichtentyp vom Zieldienst zurückgegeben wird
- Eine Warteschlange, ein Dienst und eine Aktivierungsprozedur für das Ziel
- Die Warteschlange stellt die Speicherung von Nachrichten bereit, die vom Initiatordienst an den Zieldienst gesendet werden
- Die Aktivierungsprozedur automatisiert die Verarbeitung von Nachrichten aus der Warteschlange
- Gibt eine abgeschlossene Nachricht an den Initiatordienst zurück, wenn er die Verarbeitung einer angeforderten Aufgabe abgeschlossen hat
- Verarbeitet die Systemmeldungstypen http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog und http://schemas.microsoft.com/SQL/ServiceBroker/Error
- Eine Warteschlange, ein Dienst und eine Aktivierungsprozedur für den Initiator
- Die Warteschlange stellt die Speicherung von Nachrichten bereit, die an den Dienst gesendet werden
- Die Aktivierungsprozedur ist optional, automatisiert aber die Verarbeitung von Nachrichten aus der Warteschlange
- Verarbeitet die fertige Nachricht an den Zieldienst und beendet die Konversation
- Verarbeitet die Systemmeldungstypen http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog und http://schemas.microsoft.com/SQL/ServiceBroker/Error
Zusätzlich zu diesen grundlegenden Komponenten verwende ich lieber eine gespeicherte Wrapper-Prozedur zum Erstellen einer Konversation und zum Senden von Nachrichten zwischen Maklerdiensten, um den Code sauber zu halten und die Skalierung nach Bedarf zu vereinfachen, indem die Wiederverwendung von Konversationen oder der in erläuterte 150-Konversationstrick implementiert wird das Whitepaper des SQLCAT-Teams. Für viele der einfachen asynchronen Verarbeitungskonfigurationen müssen diese Techniken zur Leistungsoptimierung möglicherweise nicht implementiert werden. Durch die Verwendung einer gespeicherten Wrapper-Prozedur wird es jedoch viel einfacher, einen einzelnen Punkt im Code zu ändern, anstatt in Zukunft jede Prozedur zu ändern, die eine Nachricht sendet, falls dies erforderlich werden sollte.
Wenn Sie sich Service Broker noch nicht angesehen haben, bietet es möglicherweise eine alternative Methode zum asynchronen Ausführen einer entkoppelten Verarbeitung, um eine Reihe möglicher Szenarien zu lösen. In meinem nächsten Beitrag gehen wir den Quellcode für eine Beispielimplementierung durch und erklären, wo bestimmte Änderungen vorgenommen werden müssten, um den Code für die asynchrone Verarbeitung zu nutzen.
