Czy oddzielasz poziomy sieci i bazy danych przez MSMQ od konieczności lub przesady?

Question

Łączę prosty kontroler web asp.net, który w wyniku posta formularza ajax wstawia rekord do bazy danych MSQL.

Jest możliwe, że strona zawierająca tę kontrolkę otrzyma wiele tysięcy odsłon w małym przedziale czasu i martwię się o problem z wydajnością otwierania połączenia z bazą danych, wstawiania rekordu, a następnie zamykania połączenia dla każdego żądania .

Rozwiązaniem, które mi się przydarzyło, jest spowodowanie, że kontrola sieci umieszcza komunikat w kolejce MSMQ i ma usługę Windows na serwerze, okresowo czytając kolejkę i wstawiając wsad.

Czy to brzmi jak rozsądna architektura, ponieważ serwery internetowe i bazy danych działają na tym samym komputerze. Czy to konieczne?

Z tego, co przeczytałem w bazie danych, większość korzyści wynikających z używania MSMQ wynika raczej z odporności, a nie z wydajności, więc mógłbym wyskakiwać z niewłaściwego drzewa.

Wszelkie porady byłyby bardzo wdzięcznością doceniane

Dziękujemy

Pete

Answer 1

Rozpatrywanie wniosków niedostępny w ten sposób jest to wspólny wzór, gdy masz do czynienia z dużą liczbą wniosków.

To, czy powinieneś, a może to zrobić, zależy od wielu czynników.

Głównym czynnikiem jest: czy Twoi rozmówcy muszą synchronicznie widzieć odpowiedź na ich zapytania?

Co mam na myśli, to czy osoba dzwoniąca musi natychmiast i z całą pewnością stwierdzić, czy baza danych poprawnie wykonała swoje dane w ramach odpowiedzi na połączenie? Jeśli tak, to przyjęcie przetwarzania żądania w trybie offline nie jest tak naprawdę opcją.

Jednakże, jeśli jest dopuszczalne, że dzwoniący mogą otrzymać odpowiedź, że ich żądanie zostanie przetworzone w trybie offline (i wszelkie wymagane odpowiedzi również wysłane w trybie offline), to korzystanie z kolejki z pewnością będzie korzystne dla ogólnej architektury.

Pierwszą rzeczą, która zostanie wykorzystana, są problemy z dostępnością front-end.

Jeśli przetwarzasz tysiące żądań przez krótki czas, a każde żądanie jest obsługiwane przez wątek, który następnie znika i wstawia dane do bazy danych, najprawdopodobniej natkniesz się na problem, w którym nie ma dostępnego wątku dyspozytora obsługa żądań przychodzących.

Jednak zmniejszając ilość zadań zaplecza, które wykonuje IIS (zapisywanie do lokalnej kolejki jest naprawdę tanie w stosunku do wywołania bazy danych), zmniejszasz także prawdopodobieństwo awarii opartej na dostępności.

Po drugie, używając kolejki, będziesz mieć możliwość dławienia ruchu z powrotem, ponieważ masz kontrolę nad przepustowością w przetwarzaniu zaplecza.

Na przykład można mieć proces jednowątkowego procesu czytnika kolejki, który usuwa kolejkowanie żądania i przetwarza je w bazę danych. Jeśli zauważysz, że masz wiadomości budowane w kolejce, możesz po prostu skalować usługę czytnika kolejek, udostępniając więcej jej instancji.

Co to oznacza, że ​​zmniejszasz prawdopodobieństwo problemów z rywalizacją bazy danych, ponieważ masz większą kontrolę nad liczbą dostępów do wątków w bazie danych w tym samym czasie.

Tak więc, używając kolejkowania, użytkownik ma mniej awarii i ma niższe koszty zarządzania, które są cechą dobrze napisanych aplikacji. Jest to szczególnie ważne, gdy rozważasz hosting bazy danych na swoim serwerze internetowym!

Należy również zapoznać się z wzorcem architektonicznym o nazwie CQRS, którego jedną z głównych zasad jest wykonywanie zapisywania bazy danych w trybie offline.

Answer 2

Architektura asynchroniczna ma wiele zalet (identyfikowanych przez Hugh), ale zdecydowanie wiąże się z większymi kosztami i złożonością. To powinno być starannie wyważone. Od 2 komponentów (aplikacja internetowa i DB) będziesz musiał opracować, utrzymywać i monitorować 4 komponenty (aplikacja internetowa, DB, usługa wsadowa, MSMQ). Powiedziałeś, że serwer WWW i serwer DB to ta sama maszyna, która jest dziwna biorąc pod uwagę twoje wymagania wydajnościowe. Jutro może będziesz musiał obsługiwać aplikację internetową, usługę wsadową, a DB to 3 oddzielne maszyny. Teraz MSMQ obejmuje również sieć. Jeszcze jedna rzecz, która może pójść nie tak. Wielowątkowy procesor wsadowy również nie jest łatwy, co jeśli trzeba przetworzyć każdą wiadomość w sekwencji, w której zostały wygenerowane (przynajmniej dla danej jednostki) logika może stać się skomplikowana.

Jeśli to możliwe, zmierz oba rozwiązania i zdecyduj.