Plusy i minusy korzystania z selera w porównaniu z RQ [zamknięte]

Obecnie pracuję nad projektem w Pythonie, który wymaga zaimplementowania niektórych zadań w tle (głównie do wysyłania e-maili i rozbudowanych aktualizacji baz danych). Używam Redis jako brokera zadań. W tym miejscu mam dwóch kandydatów: Seler i RQ . Miałem pewne doświadczenie z tymi kolejkami pracy, ale chcę prosić was o podzielenie się doświadczeniami związanymi z korzystaniem z tych narzędzi. Więc.

1. Jakie zalety i wady używać Selery vs.RQ.
2. Wszelkie przykłady projektów / zadań odpowiednich do użycia Selery vs.RQ.

Seler wygląda dość skomplikowanie, ale jest w pełni funkcjonalnym rozwiązaniem. Właściwie nie sądzę, żebym potrzebował wszystkich tych funkcji. Z drugiej strony RQ jest bardzo prosty (np. Konfiguracja, integracja), ale wydaje się, że brakuje mu kilku przydatnych funkcji (np. Odwoływanie zadań, automatyczne przeładowywanie kodu)

Oto, co znalazłem, próbując odpowiedzieć dokładnie na to samo pytanie. Prawdopodobnie nie jest to wyczerpujące, a nawet w niektórych punktach może być niedokładne.

Krótko mówiąc, RQ ma być prostsze pod każdym względem. Seler ma być bardziej wytrzymały. Obie są doskonałe.

• Dokumentacja. Dokumentacja RQ jest wyczerpująca, ale nie jest skomplikowana i odzwierciedla ogólną prostotę projektu - nigdy nie czujesz się zagubiony ani zdezorientowany. Dokumentacja selera jest również obszerna, ale spodziewaj się, że będziesz ją odwiedzać ponownie, kiedy najpierw konfigurujesz, ponieważ jest zbyt wiele opcji do internalizacji

• Monitorowanie. Kwiat selera i pulpit nawigacyjny RQ są bardzo proste w konfiguracji i zapewniają co najmniej 90% wszystkich informacji, których kiedykolwiek chciałbyś

• Wsparcie brokera. Seler jest wyraźnym zwycięzcą, RQ obsługuje tylko Redis. Oznacza to mniej dokumentacji na temat tego, „czym jest broker”, ale także oznacza, że ​​nie można zmieniać brokerów w przyszłości, jeśli Redis już dla Ciebie nie działa. Na przykład Instagram rozważał zarówno Redis, jak i RabbitMQ z Celery . Jest to ważne, ponieważ różni brokerzy mają różne gwarancje, np. Redis nie może (pisząc) zagwarantować 100%, że Twoje wiadomości zostaną dostarczone.

• Kolejki priorytetowe. Model kolejki priorytetów RQ jest prosty i efektywny - pracownicy czytają z kolejki po kolei . Seler wymaga obracania wielu pracowników, aby konsumować z różnych kolejek. Oba podejścia działają

• Obsługa systemu operacyjnego. Seler jest tutaj wyraźnym zwycięzcą, ponieważ RQ działa tylko na systemach obsługujących forknp. Systemy Unix

• Wsparcie językowe. RQ obsługuje tylko Python, podczas gdy Celery umożliwia wysyłanie zadań z jednego języka do innego języka

• API. Seler jest niezwykle elastyczny (wiele backendów wyników, ładny format konfiguracji, obsługa kanwy przepływu pracy), ale naturalnie ta moc może być myląca. Natomiast interfejs API RQ jest prosty.

• Obsługa podzadań. Seler obsługuje podzadania (np. Tworzenie nowych zadań z istniejących zadań). Nie wiem, czy RQ tak

• Społeczność i stabilność. Seler jest prawdopodobnie bardziej zakorzeniony, ale oba są aktywnymi projektami. W chwili pisania, Celery ma około 3500 gwiazdek na Github, podczas gdy RQ ma ~ 2000 i oba projekty wykazują aktywny rozwój

Moim zdaniem, Seler nie jest tak skomplikowany, jak mogłoby się wydawać, że jego reputacja mogłaby Cię przekonać, ale będziesz musiał skorzystać z RTFM.

Dlaczego więc ktoś miałby chcieć wymienić (prawdopodobnie bardziej funkcjonalny) seler na RQ? Moim zdaniem wszystko sprowadza się do prostoty. Ograniczając się do Redis + Unix, RQ zapewnia prostszą dokumentację, prostszą bazę kodów i prostsze API. Oznacza to, że Ty (i potencjalni współpracownicy twojego projektu) możesz skupić się na kodzie, na którym Ci zależy, zamiast trzymać w pamięci roboczej szczegóły dotyczące systemu kolejkowania zadań. Wszyscy mamy ograniczenie co do tego, ile szczegółów może znajdować się w naszej głowie naraz, a eliminując potrzebę przechowywania w nich szczegółów kolejki zadań, RQ pozwala wrócić do kodu, na którym Ci zależy. Ta prostota odbywa się kosztem funkcji, takich jak międzyjęzykowe kolejki zadań, szeroka obsługa systemu operacyjnego, w 100% niezawodne gwarancje wiadomości i możliwość łatwego przełączania brokerów wiadomości.

Seler nie jest taki skomplikowany. Zasadniczo wykonujesz konfigurację krok po kroku z poziomu tutorials, tworzysz celeryinstancję, dekorujesz swoją funkcję, a @celery.tasknastępnie uruchamiasz zadanie za pomocą my_task.delay(*args, **kwargs).

Sądząc po własnej ocenie, wydaje się, że musisz wybrać między brakiem (kluczowymi) funkcjami lub nadmiarem. W mojej książce nie jest to zbyt trudny wybór.