Kolejka wiadomości. Baza danych a dedykowane MQ

Jestem po radach dotyczących kolejkowania wiadomości. Mamy wymagania dotyczące wysyłania „zadań” do kolejki komunikatów.

Oryginalna sugestia polegała na użyciu instancji SQL Server i przetwarzaniu komunikatów z tego. Wszystko, co przeczytałem w Internecie, sugeruje, że korzystanie z bazy danych dla kolejki wiadomości nie jest rozwiązaniem skalowalnym. Z tego powodu zasugerowano pomysł użycia RabbitMQ lub innego MQ innej firmy.

Inną rzeczą, którą należy wziąć pod uwagę, jest to, że wymóg „przetwarzania zadania” nie będzie mniejszy niż 30 sekund, więc proces wykonujący zadanie będzie sondował bazę danych co 30 sekund. Dla mnie nie wydaje się to takie złe i prawdopodobnie działałoby dobrze bez dodawania dużego obciążenia do bazy danych.

Mamy już bazę danych na naszych klientach, której moglibyśmy użyć w tym celu, aby nie dodawała wiele dodatkowego wsparcia wymaganego dla naszych klientów, podczas gdy gdybyśmy dodali MQ innej firmy, byłoby dodatkowe wsparcie dla konfiguracji sieci itp., Które byłoby znaczna, biorąc pod uwagę, że jest wielu użytkowników.

Inną rozważaną przeze mnie opcją było umożliwienie użytkownikom wyboru między nimi. Jeśli są małym użytkownikiem, rozwiązanie Sql Server będzie w porządku, ale jeśli są większym użytkownikiem, pozwalamy im skonfigurować rozwiązanie MQ innej firmy.

Nie sprzedaje mnie żadne rozwiązanie, zastanawiam się, czy ktoś ma coś, co powinienem rozważyć lub doradzić.

Wszystko, co przeczytałem w Internecie, sugeruje, że korzystanie z bazy danych dla kolejki wiadomości nie jest rozwiązaniem skalowalnym.

Rzeczywistość często ignorowana przez „ nie używaj X, ponieważ nie skaluje się ” (link zawiera język, który niektórzy mogą uznać za nieodpowiedni), tłum jest taki, że skala nie zawsze jest ważna. Posunąłbym się nawet do stwierdzenia, że ​​jeśli spojrzysz łącznie na każde zastosowanie na powierzchni planety, skala jest rzadko ważna.

Twój komentarz przytacza stawkę 20 000 wiadomości dziennie, co oznacza, że ​​będziesz potrzebować obsługiwać średnią szybkość 0,23 wiadomości na sekundę (jedna co 4,3 sekundy). Jeśli twój projekt okaże się o dwa rzędy wielkości większy niż oczekiwano, Twoje wymagania skaczą do przetwarzania 23 wiadomości na sekundę, co byłoby dla mnie bardzo wygodne, dając mój czteroletni telefon komórkowy lub Raspberry Liczba Pi. To nadal nie jest aplikacją na dużą skalę, nawet jeśli przyłączysz do tego jeszcze kilka rzędów wielkości.

Widziałem (na szczęście z boku) projekty źle się kończą, ponieważ albo spędzały zbyt dużo czasu zbyt wcześnie na obsesję na punkcie skali, która nie miała się wydarzyć, albo nie było na niej czasu i zostały zmiażdżone przez skalę, która ostatecznie się skończyła. Jak wszystko inne, istnieje wesołe medium. Jeśli uważasz, że duże skalowanie aplikacji jest realistyczną możliwością, nie powinno być trudno uzasadnić biznesową wykonaniem niewielkiej ilości dodatkowej pracy, aby zbudować wystarczającą abstrakcję wokół nieskalowalnych części, które są niedrogie do wdrożenia teraz . Oznacza to, że później , jeśli pojawi się potrzeba skalowania, masz sposób (i być może przychód) na hurtową wymianę tych części bez konieczności ponownego przemyślenia całego systemu.

Chociaż ilość komunikatów w aplikacji nie sprawi, że baza danych lub system kolejkowania wiadomości nie spocą się nawet na skromnym sprzęcie, prawdopodobnie masz inne wymagania dotyczące obsługi transakcji wiadomości, które czynią jedną lub drugą lepszą decyzją. Te wymagania należy ocenić.

Kolejki wiadomości naprawdę sprawdzają się, gdy masz ich wiele, i przekierowujesz między nimi wiadomości, wachlując do więcej niż jednego klienta itp.

Jeśli masz tylko jedną „kolejkę zadań” rzeczy, które chcesz przetwarzać „off-line”, tabela SQL będzie w porządku.

Nie zapomnij upewnić się, że masz możliwość oznaczania trwających zadań, czyszczenia starych i powiadamiania o zatrzymaniu systemu. Jednak w przypadku pojedynczej kolejki ręczne zarządzanie tymi czynnościami będzie mniej pracochłonne niż utrzymywanie osobnego rozwiązania do kolejkowania.

Jak inni wspominali, skala prawdopodobnie nie jest tutaj ważna. Problemem w stosowaniu dwóch różnych mechanizmów przechowywania jest integralność transakcyjna.

Jeśli korzystasz z dedykowanej kolejki komunikatów, w razie awarii musisz wybrać jedną z poniższych opcji.

1. Pozwól, że dane mogą znajdować się na MB, ale nie na DB
2. Pozwól, że dane mogą być w db, ale nie w mb
3. Skonfiguruj dwufazowe zatwierdzanie lub transakcje rozproszone między db a mq, co może być skomplikowane

Wszystkie te problemy znikają, jeśli zapisujesz dane tylko w jednym miejscu przy użyciu zwykłej transakcji. Z tego powodu używanie db jako kolejki zadań jest idealnym rozwiązaniem.

Ze względów praktycznych główne powody, dla których używam kolejki komunikatów, to:

• Nie musiałem od nowa wymyślać koła. Zaprojektowanie nawet najprostszej kolejki komunikatów przy użyciu bazy danych wymaga co najmniej kilku godzin myślenia, kilku godzin kodowania i tak dalej. W porównaniu do implementacji kolejki komunikatów czas potrzebny do skonfigurowania i / lub zautomatyzowania konfiguracji jest prosty
• Kolejki wiadomości mają ładny i przejrzysty interfejs dla producenta i konsumenta. Jest to prawdopodobnie najważniejsza rzecz w pisaniu aplikacji. Bez interfejsu kolejki komunikatów są w zasadzie tylko zbiorem danych
• Kolejki wiadomości zapewniają więcej funkcji, które mogą być potrzebne w przyszłości

Jeśli chodzi o umożliwienie użytkownikom wyboru, to naprawdę szczegół implementacji, na który użytkownicy nie powinni się przejmować. Użytkownicy powinni uzyskać ten sam interfejs i nie powinno być różnicy dla użytkowników, jeśli używana jest baza danych lub kolejka komunikatów. Po ustawieniu jednego projektu prawdopodobnym wyborem dla użytkowników jest liczba węzłów, które należy wdrożyć, aby uwzględnić ich potrzeby.

Stworzyłem rozwiązanie kolejki komunikatów Mssql, które może obsłużyć 20 000 operacji na sekundę, zgodnie z testem wydajności i potrzebujemy 10 sekund na sekundę. Myślę, że fakt, że możesz mieć wbudowany priorytet, jest cechą, której brakuje dedykowanej kolejce komunikatów. I to był główny wymóg w moim przypadku.