Od Hangfire do RabbitMQ: Koniec z odpytywaniem bazy danych

Hangfire jest świetny dla małych zespołów. Dodajesz pakiet NuGet i wskazujesz swoją bazę danych. Otrzymujesz runner zadań i dashboard za darmo. W przypadku pojedynczego serwisu trudno o lepsze rozwiązanie.

Używałem Hangfire w SavePosty do obsługi e-maili, webhooków i pobierania treści. Każde zadanie działało w ten sam sposób. Wszystkie odpytywały moją bazę Postgres co kilka sekund, aby sprawdzić, czy pojawiły się nowe zadania.

Ostatecznie przenieśliśmy wszystko do RabbitMQ. Oto dlaczego to zrobiłem i co przez to straciłem.

Dlaczego się przeniosłem:

• Obciążenie wynikające z odpytywania skaluje się wraz z czasem, a nie z ilością pracy. Każde zadanie Hangfire uderza w bazę danych zgodnie z harmonogramem. Nawet jeśli nie ma pracy, baza pozostaje zajęta. Ten koszt rośnie wraz z liczbą zadań i częstotliwością odpytywania.
• Zbyt wiele modeli. Jedna część mojej aplikacji już korzystała z RabbitMQ. Reszta używała Hangfire. Oznaczało to dwa różne sposoby zarządzania pracą w tle. Przejście na RabbitMQ ujednoliciło wszystko.
• Opóźnienia (Latency). Broker przesyła zadanie w momencie jego nadejścia. Hangfire czeka na kolejne odpytanie.

Kompromisy:

Hangfire jest łatwy w konfiguracji. Wykorzystuje istniejące tabele SQL. Posiada świetny, wbudowany dashboard.

RabbitMQ wymaga zarządzania brokerem. Wykorzystuje RAM i sieć zamiast procesora bazy danych. Otrzymujesz lepszą skalowalność, ale większy narzut operacyjny.

Jak przeprowadziłem bezpieczną migrację:

Zachowałem logikę biznesową w niezmienionej formie. Zbudowałem lekkie konsumentów (consumers), którzy pełnią rolę „wejścia”. Konsument odbiera wiadomość i przekazuje ją do istniejącej klasy zadania.

Skupiłem się na dwóch rzeczach:

• Zgodność mechanizmu ponowień (Retry parity). Dopasowałem ustawienia ponowień Hangfire w konsumencie RabbitMQ, aby nie zgubić wiadomości.
• Bezpieczeństwo schematu. Pozostawiłem stare kolumny jako dopuszczające wartości NULL (nullable), aby nie uszkodzić bazy danych podczas wdrożenia.

Co straciłem:

Największą wadą jest widoczność. Hangfire pozwala kliknąć w nieudane zadanie i zobaczyć dokładnie, co się stało. RabbitMQ pokazuje, ile wiadomości znajduje się w Dead Letter Queue, ale nie zapewnia tak łatwego podglądu dla każdego zadania z osobna. Teraz polegam na ustrukturyzowanych logach zamiast na dashboardzie.

Moja rada:

Zostań przy Hangfire, jeśli:

• Uruchamiasz pojedynczy serwis.
• Masz mały zespół.
• Potrzebujesz prostego dashboardu do debugowania.

Przejdź na RabbitMQ, jeśli:

• Masz wiele serwisów.
• Obciążenie bazy danych wynikające z odpytywania jest wysokie.
• Chcesz korzystać z wzorców pub/sub.

Decyzja zależy od Twojego systemu, a nie od pojedynczego zadania.

Source: https://dev.to/gabrielleroux/from-hangfire-to-rabbitmq-killing-database-polling-in-a-net-app-4og4

Optional learning community: https://t.me/GyaanSetuAi