6 najlepszych systemów kolejkowych dla programistów zaplecza

Poszukujesz systemu do obsługi zadań w kolejkach? A może pragniesz rozwiązania o wyższych możliwościach? W tym artykule znajdziesz kompleksowe informacje na ten temat!

Systemy kolejkowe to kluczowy element, często pomijany w dyskusjach o rozwoju backendu.

Nie chcąc tworzyć laurki na cześć systemów kolejkowych, stwierdzę, że młody programista backendu awansuje na poziom średnio zaawansowanego, gdy nauczy się skutecznie integrować kolejki z systemem. Kolejki znacząco wpływają na komfort użytkownika (o czym przekonamy się dalej), obniżają złożoność i zwiększają niezawodność systemu.

Oczywiście, w przypadku bardzo prostych aplikacji internetowych, o znikomym ruchu, czy stron typu wizytówki, systemy kolejkowe mogą być zbyteczne, a nawet niemożliwe do wdrożenia, szczególnie w standardowych środowiskach hostingu współdzielonego. Jednak bardziej rozbudowane aplikacje zyskują na ich wykorzystaniu, a duże systemy wręcz nie mogą się bez nich obejść.

Zanim przejdziemy dalej, drobne zastrzeżenie: jeśli masz już doświadczenie z systemami kolejkowymi i chcesz dokonać porównania różnych dostępnych opcji, kolejne sekcje wprowadzenia mogą Cię nieco znudzić. Nie wahaj się więc przejść od razu do interesujących Cię fragmentów. Wprowadzenie jest przeznaczone dla osób, które mają jedynie ogólne pojęcie o systemach kolejkowych lub słyszały o nich tylko przelotnie.

Czym jest system kolejkowy?

Zacznijmy od zrozumienia, czym właściwie jest kolejka.

Kolejka, w kontekście informatycznym, to struktura danych, która odzwierciedla realne kolejki spotykane na co dzień. Wyobraź sobie, że stoisz w kolejce do kasy biletowej. Zauważysz, że musisz ustawić się na końcu, a osoba na początku zostanie obsłużona jako pierwsza. To właśnie zasada „pierwszy przyszedł, pierwszy obsłużony”. W programowaniu, możliwe jest stworzenie programów, które przechowują zadania w kolejce i przetwarzają je jedno po drugim, zgodnie z tą samą zasadą.

Warto zaznaczyć, że kolejka sama w sobie nie wykonuje żadnych obliczeń. Jest to jedynie miejsce tymczasowego przechowywania zadań, które oczekują na podjęcie przez odpowiedni proces. Jeśli brzmi to dla Ciebie zbyt abstrakcyjnie, nie martw się, w następnej sekcji omówimy konkretne przykłady.

Dlaczego warto stosować systemy kolejkowe?

Nie zagłębiając się w szczegółowy opis, głównym powodem używania systemów kolejkowych jest możliwość przetwarzania zadań w tle, wykonywania ich równolegle oraz odzyskiwanie systemu po awarii. Przyjrzyjmy się temu na konkretnych przykładach:

Przetwarzanie w tle

Załóżmy, że prowadzisz kampanię marketingową w e-commerce, gdzie czas odgrywa istotną rolę. Twoja aplikacja jest skonstruowana tak, że wysyła wiadomość e-mail z potwierdzeniem tuż przed sfinalizowaniem płatności i wyświetleniem strony z podziękowaniem. Jeśli serwer pocztowy, z którym się łączysz, przestanie działać, strona internetowa również przestanie działać, co negatywnie wpłynie na doświadczenia użytkowników.

Wyobraź sobie lawinę zgłoszeń do działu wsparcia, które na pewno otrzymasz w takiej sytuacji. W takim przypadku o wiele lepiej jest przenieść zadanie wysyłania e-maili do kolejki zadań i jednocześnie pokazać klientowi stronę potwierdzenia transakcji.

Wykonywanie równoległe

Wielu programistów, zwłaszcza tych, którzy tworzą prostsze aplikacje o małym ruchu, ma tendencję do używania zadań cron do przetwarzania w tle. Jest to wystarczające, dopóki ilość danych do przetworzenia nie osiągnie poziomu, którego nie da się obsłużyć. Przykładowo, masz zadanie crona, które generuje raporty analityczne i wysyła je e-mailem do użytkowników. Twój system jest w stanie przetworzyć 100 raportów na minutę.

W miarę rozwoju aplikacji i wzrostu liczby zapytań do ponad 100 na minutę, system zacznie mieć coraz większe opóźnienia i nigdy nie nadrobi zaległości w przetwarzaniu zadań.

W systemie kolejkowym można uniknąć takiej sytuacji, konfigurując wielu tzw. workerów, z których każdy może pobrać zadanie (na przykład pakiet 100 raportów) i pracować równolegle, znacznie przyspieszając proces.

Odzyskiwanie po awarii

Jako twórcy stron internetowych, często nie bierzemy pod uwagę ewentualnych awarii. Zakładamy, że nasze serwery i wykorzystywane API będą zawsze dostępne. Rzeczywistość jest jednak inna – awarie sieci zdarzają się zbyt często, a nawet najbardziej niezawodne API, na których polegamy, mogą przestać działać z powodu problemów z infrastrukturą. (Zanim powiesz „mnie to nie dotyczy”, przypomnij sobie ogromną awarię Amazon S3). Wracając do przykładu z raportami, jeśli generowanie raportu wymaga połączenia z Payment API, a to połączenie jest niedostępne przez 2 minuty, co stanie się z 200 raportami, które nie zostały wygenerowane?

Systemy kolejkowe wiążą się jednak z pewnymi wyzwaniami. Krzywa uczenia się jest dość stroma, gdy wchodzimy w zupełnie nową dziedzinę. Zwiększa się też złożoność aplikacji oraz samego wdrożenia. Poza tym nie zawsze mamy 100% kontrolę nad zadaniami w kolejce. Mimo wszystko, w niektórych sytuacjach budowanie aplikacji bez systemów kolejkowych jest po prostu niemożliwe.

Zostawiając te kwestie z boku, przyjrzyjmy się typowym opcjom systemów kolejkujących dostępnym na rynku.

Redis

Redis jest znany jako magazyn danych typu klucz-wartość, służący do przechowywania, aktualizacji i pobierania ciągów danych bez znajomości ich struktury. Choć tak mogło być na początku, obecnie Redis posiada efektywne i bardzo przydatne struktury danych, takie jak listy, zbiory sortowane, a nawet system Pub-Sub. Dzięki temu jest chętnie wykorzystywany w implementacjach kolejek.

Zalety Redis to:

• Baza danych działająca całkowicie w pamięci RAM, co skutkuje szybszym odczytem/zapisem.
• Wysoka wydajność: jest w stanie bez problemu obsłużyć ponad 100 000 operacji odczytu/zapisu na sekundę.
• Elastyczny schemat trwałości danych. Możesz wybrać maksymalną wydajność kosztem potencjalnej utraty danych w przypadku awarii lub skonfigurować tryb w pełni konserwatywny, rezygnując z części wydajności na rzecz spójności danych.
• Wbudowana obsługa klastrów.

Warto pamiętać, że Redis nie posiada wbudowanych abstrakcji dla przesyłania wiadomości/kolejkowania/odzyskiwania danych. Konieczne jest więc użycie dodatkowej biblioteki lub samodzielne stworzenie prostego systemu. Przykładowo, Redis jest domyślnym backendem kolejki dla frameworka Laravel PHP, w którym mechanizm harmonogramowania zadań został zaimplementowany przez twórców frameworka.

Nauka Redis nie jest trudna.

RabbitMQ

Istnieje kilka subtelnych, ale istotnych różnic między Redis a RabbitMQ, które warto omówić na początku.

Przede wszystkim, RabbitMQ ma bardziej specjalistyczną, precyzyjnie zdefiniowaną rolę – przesyłanie wiadomości. Innymi słowy, jego główną funkcją jest działanie jako pośrednik między dwoma systemami. Nie jest to cecha Redisa, który funkcjonuje bardziej jak baza danych. W konsekwencji, RabbitMQ zapewnia szereg dodatkowych ułatwień, których brakuje w Redis, takich jak routing wiadomości, ponawianie prób, dystrybucja obciążenia itp.

Jeśli się nad tym zastanowić, kolejki zadań można również traktować jako system przesyłania wiadomości, gdzie harmonogram zadań, pracownicy i komponent „przesyłający” zadania działają jako elementy biorące udział w procesie przekazywania wiadomości.

RabbitMQ ma następujące zalety:

• Bardziej zaawansowane abstrakcje do przekazywania wiadomości, które zmniejszają zakres pracy na poziomie aplikacji, jeśli potrzebujesz przesyłania wiadomości.
• Większa odporność na awarie zasilania i przerwy w dostawie prądu (przynajmniej domyślnie w porównaniu z Redis).
• Obsługa klastrów i federacji dla wdrożeń rozproszonych.
• Przydatne narzędzia do zarządzania i monitorowania wdrożeń.
• Obsługa praktycznie wszystkich popularnych języków programowania.
• Łatwość wdrożenia z pomocą wybranych narzędzi (Docker, Chef, Puppet itp.).

Kiedy warto wybrać RabbitMQ? Jest to doskonały wybór, jeśli wiesz, że potrzebujesz asynchronicznego przesyłania wiadomości, ale nie jesteś jeszcze gotowy, aby zmierzyć się z dużą złożonością niektórych innych systemów kolejkowania z tej listy (opisane poniżej).

ActiveMQ

Jeśli interesujesz się rozwiązaniami korporacyjnymi (lub tworzysz wysoce rozproszoną aplikację na dużą skalę) i nie chcesz za każdym razem tworzyć wszystkiego od nowa (i przy okazji popełniać błędów), warto przyjrzeć się ActiveMQ.

Oto, co wyróżnia ActiveMQ:

• Jest zaimplementowany w Javie, co zapewnia bardzo dobrą integrację z tym językiem (jest zgodny ze standardem JMS).
• Obsługuje wiele protokołów: AMQP, MQTT, STOMP, OpenWire itp.
• Oferuje gotową obsługę bezpieczeństwa, routingu, wygaśnięcia wiadomości, analityki itp.
• Wbudowana obsługa popularnych wzorców wiadomości rozproszonych, oszczędzająca czas i potencjalne błędy.

Warto zaznaczyć, że ActiveMQ nie jest ograniczony tylko do Javy. Posiada klientów dla Pythona, C/C++, Node, .Net i innych ekosystemów, więc nie powinieneś obawiać się potencjalnych problemów z rozwojem w przyszłości. Dodatkowo ActiveMQ jest zbudowany na otwartych standardach, co ułatwia tworzenie własnych, lekkich klientów.

Pamiętaj, że ActiveMQ jest tylko brokerem, a nie pełnym backendem. Do przechowywania wiadomości będziesz potrzebować jednego z obsługiwanych backendów. Umieściłem go tutaj, ponieważ nie jest tak bardzo związany z konkretnym językiem programowania (jak popularne rozwiązania typu Celery, Sidekiq itp.).

Amazon MQ

Amazon MQ zasługuje na krótką, ale istotną wzmiankę. Jeśli uważasz, że ActiveMQ jest idealnym rozwiązaniem dla Twoich potrzeb, ale nie chcesz zajmować się samodzielnie budową i utrzymywaniem całej infrastruktury, Amazon MQ oferuje usługę zarządzaną w tym zakresie. Obsługuje wszystkie protokoły, które wspiera ActiveMQ – nie ma żadnej różnicy w funkcjonalności, ponieważ Amazon MQ korzysta z ActiveMQ „pod maską”.

Zaletą tego rozwiązania jest to, że jest to usługa zarządzana, więc nie musisz się martwić o nic innego, jak o samo korzystanie z niej. Ma to szczególny sens w przypadku wdrożeń w AWS, ponieważ możesz korzystać z innych usług i ofert bezpośrednio z poziomu wdrożenia (np. szybkie przesyłanie danych).

Amazon SQS

Nie możemy oczekiwać, że Amazon pozostanie w tyle, jeśli chodzi o tak kluczowe elementy infrastruktury, prawda?

Dlatego mamy Amazon SQS, czyli w pełni hostowaną, prostą usługę kolejek (dosłownie) od znanego giganta AWS. Tutaj również istotne są subtelne różnice. Pamiętaj, że SQS nie ma koncepcji przekazywania wiadomości. Podobnie jak Redis, jest to prosty backend do przyjmowania i dystrybucji zadań w kolejkach.

Kiedy więc warto rozważyć użycie Amazon SQS? Oto kilka powodów:

• Jesteś entuzjastą AWS i nie chcesz używać niczego innego (wiele osób tak robi i nie ma w tym nic złego).
• Potrzebujesz rozwiązania hostowanego, które gwarantuje zerowy wskaźnik awarii i brak utraconych zadań.
• Nie chcesz samodzielnie tworzyć klastrów i monitorować ich działania. Albo, co gorsza, nie chcesz tworzyć narzędzi monitorujących, zamiast wykorzystać ten czas na produktywny rozwój.
• Masz już znaczne inwestycje w platformę AWS i bycie zamkniętym w tym ekosystemie ma sens z punktu widzenia biznesu.
• Potrzebujesz prostego systemu kolejkowania bez zbędnych komplikacji związanych z przesyłaniem wiadomości, protokołami itp.

Podsumowując, Amazon SQS to solidny wybór dla każdego, kto chce zaimplementować kolejki zadań w swoim systemie i nie chce tracić czasu na samodzielną instalację i monitorowanie.

Beanstalkd

Beanstalkd to usługa, która funkcjonuje już od dłuższego czasu. Jest to sprawdzone, szybkie i łatwe w konfiguracji rozwiązanie do kolejek zadań. Istnieje kilka cech, które odróżniają Beanstalkd od Redisa:

• To system kolejki zadań i nic więcej. Wstawiasz do niego zadania, które później są pobierane przez procesy worker. Jeśli Twoja aplikacja wymaga jakiejkolwiek formy przekazywania wiadomości, Beanstalkd nie będzie dobrym wyborem.
• Nie oferuje zaawansowanych struktur danych, takich jak zbiory, kolejki priorytetowe itp.
• Beanstalkd działa w oparciu o zasadę First In, First Out (FIFO). Nie ma możliwości sortowania zadań według priorytetów.
• Nie ma opcji klastrowania.

Podsumowując, Beanstalkd jest szybkim i prostym systemem kolejkowania dla nieskomplikowanych projektów, działających na jednym serwerze. Dla wielu jest szybszy i bardziej stabilny niż Redis. Jeśli masz problemy z Redis, których nie potrafisz rozwiązać, a Twoje wymagania są proste, Beanstalkd może być wart wypróbowania.

Podsumowanie

Jeśli dotarłeś do tego miejsca (lub chociażby przejrzałeś cały artykuł), istnieje spora szansa, że interesujesz się systemami kolejkowania lub po prostu ich potrzebujesz. W takim przypadku, lista przedstawiona w tym artykule powinna Ci dobrze posłużyć, chyba że szukasz systemu kolejkowania specyficznego dla danego języka/frameworka.

Chciałbym powiedzieć, że kolejkowanie zadań jest proste i w 100% niezawodne, ale to nieprawda. Wiele rzeczy może się skomplikować, a ponieważ wszystko dzieje się w tle i bardzo szybko (błędy mogą pozostać niezauważone i stać się kosztowne). Mimo wszystko, systemy kolejkowania są niezbędne powyżej pewnego poziomu złożoności i z czasem docenisz ich moc (być może nawet staną się najpotężniejszą bronią w Twoim arsenale). Powodzenia!