Uwielbiam modyfikować kod SQL Server w celu poprawy wydajności, ale czasami zdarzają się scenariusze, w których nawet po dostrojeniu kodu, indeksowaniu i projektowaniu zadania użytkownika z aplikacji trwa dłużej niż oczekiwano. Kiedy tak się dzieje, interfejs użytkownika albo musi czekać na zakończenie procesu, albo musimy wymyślić alternatywny sposób obsługi zadania. Przetwarzanie asynchroniczne zapewniane przez Service Broker jest dobre dla wielu z tych scenariuszy i umożliwia przetwarzanie w tle długo działającego zadania niezależnie od interfejsu użytkownika, umożliwiając użytkownikowi natychmiastową kontynuację pracy bez oczekiwania na faktyczne wykonanie zadania . W kolejnych kilku artykułach mam nadzieję stworzyć serię o tym, jak można wykorzystać Service Broker z odpowiednimi wyjaśnieniami i przykładami kodu, aby ułatwić korzystanie z możliwości Service Broker bez problemów z implementacją.
Metody wykonywania przetwarzania asynchronicznego
Istnieje wiele sposobów radzenia sobie z długotrwałym, ale już dostrojonym procesem. Kod aplikacji można również przepisać, aby użyć BackgroundWorker, ThreadPool w tle lub ręcznie napisane rozwiązanie oparte na wątkach na platformie .NET, które wykonuje operację asynchronicznie. Pozwala to jednak na przesłanie przez aplikację nieograniczonej liczby tych długotrwałych procesów, chyba że zostanie wykonana dodatkowa praca kodująca w celu śledzenia i ograniczenia liczby aktywnych procesów. Oznacza to, że aplikacja będzie miała potencjalny wpływ na wydajność lub pod obciążeniem osiągnie limit i powróci do poprzedniego oczekiwania, któremu początkowo próbowaliśmy zapobiec.
Widziałem również tego typu procesy zamienione w zadania SQL Agent powiązane z tabelą, która służy do przechowywania informacji do przetworzenia. Następnie zadanie jest albo zaplanowane do okresowego uruchamiania, albo jest uruchamiane przez aplikację przy użyciu sp_start_job gdy zmiana jest przechowywana do przetworzenia. Pozwala to jednak tylko na seryjne wykonywanie długo działających procesów, ponieważ agent SQL nie pozwala na wielokrotne jednoczesne uruchamianie zadania. Zadanie musiałoby być również zaprojektowane do obsługi scenariuszy, w których wiele wierszy wchodzi do tabeli przetwarzania, tak aby wystąpiła prawidłowa kolejność przetwarzania, a kolejne zgłoszenia były przetwarzane osobno.
Wykorzystanie Service Broker do przetwarzania asynchronicznego w SQL Server faktycznie rozwiązuje ograniczenia za pomocą wcześniej wspomnianych metod obsługi przetwarzania asynchronicznego. Implementacja brokera umożliwia kolejkowanie nowych zadań w celu przetwarzania asynchronicznego w tle, a także umożliwia równoległe przetwarzanie zadań, które zostały umieszczone w kolejce do skonfigurowanego limitu. Jednak w przeciwieństwie do warstwy aplikacji, która musi czekać po osiągnięciu limitu, rozwiązanie brokera po prostu umieszcza w kolejce odbierany nowy komunikat i umożliwia jego przetworzenie po zakończeniu jednego z bieżących zadań przetwarzania — pozwala to aplikacji kontynuować bez czekania.
Konfiguracja brokera usług pojedynczej bazy danych
Chociaż konfiguracje Service Broker mogą stać się złożone, w przypadku prostego przetwarzania asynchronicznego wystarczy znać podstawowe koncepcje tworzenia konfiguracji pojedynczej bazy danych. Konfiguracja pojedynczej bazy danych wymaga tylko:
- Tworzenie dwóch typów wiadomości
- Jeden do żądania przetwarzania asynchronicznego
- Jeden dla wiadomości zwrotnej po zakończeniu przetwarzania
- Kontrakt wykorzystujący typy wiadomości
- Określa, jaki typ wiadomości jest wysyłany przez usługę inicjatora i jaki typ wiadomości jest zwracany przez usługę docelową
- Kolejka, usługa i procedura aktywacji dla celu
- Kolejka zapewnia przechowywanie wiadomości wysłanych do usługi docelowej przez usługę inicjatora
- Procedura aktywacji automatyzuje przetwarzanie wiadomości z kolejki
- Zwraca ukończoną wiadomość do usługi inicjatora po zakończeniu przetwarzania żądanego zadania
- Obsługuje typy komunikatów systemowych http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog i http://schemas.microsoft.com/SQL/ServiceBroker/Error
- Kolejka, obsługa i procedura aktywacji dla inicjatora
- Kolejka zapewnia przechowywanie wiadomości wysłanych do usługi
- Procedura aktywacji jest opcjonalna, ale automatyzuje przetwarzanie wiadomości z kolejki
- Przetwarza ukończoną wiadomość do usługi docelowej i kończy rozmowę
- Obsługuje typy komunikatów systemowych http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog i http://schemas.microsoft.com/SQL/ServiceBroker/Error
Oprócz tych podstawowych komponentów, wolę używać opakowującej procedury składowanej do tworzenia konwersacji i wysyłania wiadomości między usługami brokera, aby zachować czystość kodu i ułatwić skalowanie w razie potrzeby, wdrażając ponowne użycie konwersacji lub sztuczkę 150 konwersacji opisaną w oficjalny dokument zespołu SQLCAT. W przypadku wielu prostych konfiguracji przetwarzania asynchronicznego te techniki dostrajania wydajności mogą nie być konieczne. Jednak przy użyciu opakowującej procedury składowanej znacznie łatwiej jest zmienić pojedynczy punkt w kodzie, zamiast zmieniać każdą procedurę, która wysyła komunikat w przyszłości, jeśli okaże się to konieczne.
Jeśli nie udostępniłeś Service Brokerowi wyglądu, może on zapewnić alternatywną metodę wykonywania asynchronicznego przetwarzania oddzielonego w celu rozwiązania wielu możliwych scenariuszy. W następnym poście omówimy kod źródłowy przykładowej implementacji i wyjaśnimy, gdzie należałoby wprowadzić określone zmiany, aby wykorzystać kod do przetwarzania asynchronicznego.
