SQL Server Service Broker

Service Broker to mechanizm asynchronicznej komunikacji między aplikacjami oparty na kolejkach wewnątrz bazy.

SQL Server Service Broker jako mechanizm komunikacji asynchronicznej

SQL Server Service Broker jest składnikiem aparatu bazodanowego Microsoft SQL Server służącym do asynchronicznego przekazywania komunikatów między usługami. Komunikacja odbywa się z wykorzystaniem kolejek przechowywanych w bazie danych, dzięki czemu nadawca nie musi czekać na natychmiastowe wykonanie całej operacji przez odbiorcę. Żądanie może zostać zapisane w kolejce, a właściwa obsługa nastąpi później, gdy usługa odbiorcza będzie gotowa do pracy.

Mechanizm nie jest ogólnym brokerem wiadomości działającym niezależnie od SQL Server. Jego elementy, takie jak typy komunikatów, kontrakty, kolejki, usługi, trasy i endpointy, są definiowane w ramach konkretnej bazy lub współpracujących baz SQL Server. Service Broker może obsługiwać komunikację w obrębie jednej bazy, pomiędzy bazami tego samego wystąpienia, a także pomiędzy różnymi wystąpieniami SQL Server, jeśli skonfigurowano odpowiednie zabezpieczenia i routing.

Elementy modelu: komunikat, kontrakt, usługa i kolejka

Podstawą przepływu jest komunikat należący do wcześniej zdefiniowanego typu. Typ komunikatu określa między innymi sposób walidacji jego treści, na przykład brak walidacji albo walidację XML. Kontrakt wskazuje, jakie typy komunikatów mogą występować w rozmowie oraz która strona może je wysyłać. Dzięki temu Service Broker rozróżnia prawidłowo zainicjowaną komunikację od komunikatu niezgodnego z ustalonym protokołem.

Usługa jest logicznym punktem dostępu dla aplikacji, natomiast kolejka przechowuje oczekujące komunikaty i dostarcza je procesowi obsługi. Rozmowa pomiędzy usługami jest reprezentowana przez dialog albo rozmowę jednokierunkową. Dialog ma określony początek i koniec, a komunikaty należące do tej samej rozmowy zachowują kolejność. Do zakończenia dialogu służą komunikaty kończące rozmowę, między innymi wysyłane przez instrukcję END CONVERSATION. Nieusuwanie zakończonych rozmów może prowadzić do narastania metadanych i problemów administracyjnych.

W przypadku komunikacji między wystąpieniami SQL Server potrzebne są dodatkowo trasy określające miejsce docelowe usługi oraz endpoint Service Broker. Istotną rolę odgrywają także certyfikaty, użytkownicy, uprawnienia i mechanizmy uwierzytelniania. Sama obecność kolejki nie oznacza więc, że komunikacja zdalna będzie działała: konfiguracja musi obejmować zarówno obiekty aplikacyjne, jak i warstwę bezpieczeństwa transportu.

Aktywacja kolejki, odbiór wiadomości i transakcje

Wiadomości można odbierać jawnie przez aplikację albo przetwarzać automatycznie z użyciem aktywacji kolejki. Przy aktywacji SQL Server uruchamia procedurę składowaną, gdy w kolejce pojawią się komunikaty spełniające warunki aktywacji. Procedura zwykle wykonuje instrukcję RECEIVE, odczytuje określoną liczbę komunikatów, interpretuje ich treść i zapisuje wynik w tabelach lub wysyła odpowiedź do usługi inicjującej.

Instrukcja RECEIVE usuwa odebrane komunikaty z kolejki w ramach transakcji. Jeżeli transakcja zostanie wycofana, komunikaty mogą wrócić do kolejki i zostać podjęte ponownie. Z tego powodu procedura obsługi powinna być przygotowana na powtórne dostarczenie tego samego żądania. Operacje zapisu wykonane przez procedurę oraz odbiór komunikatu powinny być analizowane jako jeden przepływ transakcyjny, szczególnie wtedy, gdy błąd części operacji ma powodować ponowienie całego zadania.

Do obsługi błędów przewidziano między innymi komunikaty błędu oraz komunikaty końca rozmowy. W praktyce należy rozdzielić błędy aplikacyjne, takie jak nieprawidłowe dane żądania, od błędów infrastruktury, takich jak brak trasy, niedostępny endpoint lub problem z uprawnieniami. Przydatne są widoki katalogowe i widoki dynamicznego zarządzania SQL Server, w tym informacje o kolejkach, rozmowach, transmission queue oraz stanie komunikatów oczekujących na wysłanie.

Diagnozowanie zablokowanych kolejek i niespójnego przepływu

Analizę problemu należy rozpocząć od ustalenia, czy komunikat został zapisany w kolejce nadawczej, przekazany do kolejki odbiorczej i odebrany przez procedurę lub aplikację. Komunikaty pozostające w sys.transmission_queue mogą wskazywać na problem z trasą, endpointem, uwierzytelnianiem, certyfikatem albo uprawnieniami. Komunikaty znajdujące się w kolejce docelowej sugerują, że dostarczenie nastąpiło, ale obsługa jeszcze się nie zakończyła lub aktywacja nie uruchamia prawidłowego procesu.

Warto sprawdzić stan kolejek w widoku sys.service_queues, aktywne rozmowy w widokach dotyczących konwersacji oraz komunikaty diagnostyczne generowane przez Service Broker. Należy również zweryfikować, czy procedura aktywowana przez kolejkę ma poprawny schemat właściciela, wymagane uprawnienia i obsługę komunikatów typu http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog oraz http://schemas.microsoft.com/SQL/ServiceBroker/Error. Brak obsługi tych komunikatów może pozostawiać rozmowy w stanie, który wygląda jak zawieszenie przepływu.

Przy diagnozie środowiska, na którym działa SQL Server, trzeba odróżnić błąd samego silnika od problemu komputera, systemu operacyjnego, dysku lub połączenia sieciowego. Analizuje się między innymi dostępność zasobów, błędy zapisu, blokady, stan usługi SQL Server oraz ciągłość połączenia. W przypadku zastosowań serwerowych naprawa sprzętu nie zastępuje analizy konfiguracji bazodanowej: pozwala natomiast ustalić, czy niestabilność platformy wykonawczej mogła przerwać transakcje, aktywację kolejki albo dostarczanie komunikatów.